From aaa5500 at ya.ru Tue Aug 1 15:32:06 2017 From: aaa5500 at ya.ru (Alexey) Date: Tue, 1 Aug 2017 16:32:06 +0300 Subject: [Lazarus] Optimize SwapEndian for widestring? Message-ID: Pls tell can I optimize this func? E.g. calc each char's PWord and read/write word. function SSwapEndian(const S: UnicodeString): UnicodeString; var i: integer; begin Result:= S; for i:= 1 to Length(Result) do Result[i]:= WideChar(SwapEndian(Ord(Result[i]))); end; -- Regards, Alexey From michael at freepascal.org Tue Aug 1 16:15:05 2017 From: michael at freepascal.org (Michael Van Canneyt) Date: Tue, 1 Aug 2017 16:15:05 +0200 (CEST) Subject: [Lazarus] Optimize SwapEndian for widestring? In-Reply-To: References: Message-ID: On Tue, 1 Aug 2017, Alexey via Lazarus wrote: > Pls tell can I optimize this func? E.g. calc each char's PWord and > read/write word. > > Probably this will be faster: function SSwapEndian(const S: UnicodeString): UnicodeString; var i: integer; p :pwidechar; begin Result:= S; UniqueString(Result); P:=PWideChar(Result[1])); for i:= 1 to Length(Result) do begin P^:= WideChar(SwapEndian(P^)); Inc(P); end; end; From aaa5500 at ya.ru Wed Aug 2 10:22:28 2017 From: aaa5500 at ya.ru (Alexey) Date: Wed, 2 Aug 2017 11:22:28 +0300 Subject: [Lazarus] Optimize SwapEndian for widestring? In-Reply-To: References: Message-ID: <829e4e15-a4eb-2aa0-f20a-d41ae60920fe@ya.ru> Thanks, it didn't compile, this this did: function SSwapEndian(const S: UnicodeString): UnicodeString; var i: integer; p: PWord; begin Result:= S; if S='' then exit; UniqueString(Result); P:= PWord(@Result[1]); for i:= 1 to Length(Result) do begin P^:= SwapEndian(P^); Inc(P); end; end; AlexeyT From fluisgirardi at gmail.com Wed Aug 2 16:08:37 2017 From: fluisgirardi at gmail.com (Fabio Luis Girardi) Date: Wed, 2 Aug 2017 11:08:37 -0300 Subject: [Lazarus] Status of namespace Message-ID: Hi all!! Whats the current state of Lazarus when dealing with packages with dotted units (namespaces)? Should I avoid this idea? The best regards, Fabio Luis Girardi PascalSCADA Project http://sourceforge.net/projects/pascalscada http://www.pascalscada.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From md at delfire.net Wed Aug 2 16:32:11 2017 From: md at delfire.net (Marcos Douglas B. Santos) Date: Wed, 2 Aug 2017 11:32:11 -0300 Subject: [Lazarus] Status of namespace In-Reply-To: References: Message-ID: On Wed, Aug 2, 2017 at 11:08 AM, Fabio Luis Girardi via Lazarus wrote: > Hi all!! > > Whats the current state of Lazarus when dealing with packages with dotted > units (namespaces)? > > Should I avoid this idea? It's working. Best regards, Marcos Douglas From juha.manninen62 at gmail.com Wed Aug 2 16:46:40 2017 From: juha.manninen62 at gmail.com (Juha Manninen) Date: Wed, 2 Aug 2017 17:46:40 +0300 Subject: [Lazarus] Status of namespace In-Reply-To: References: Message-ID: On Wed, Aug 2, 2017 at 5:08 PM, Fabio Luis Girardi via Lazarus wrote: > Whats the current state of Lazarus when dealing with packages with dotted > units (namespaces)? Dotted unit names are supported more or less. > Should I avoid this idea? No. Instead please work with them and report problems. I found 2 related bug reports: https://bugs.freepascal.org/view.php?id=24269 - FPDoc. May not be relevant in your case. (?) https://bugs.freepascal.org/view.php?id=20892 - The original bug is fixed long time ago, but I understood there are 2 others that should be reported separately. - F12 in designer. - Codetools issues. Can you please test and report the remaining issues. I will resolve #20892 then. Juha From juha.manninen62 at gmail.com Wed Aug 2 16:50:11 2017 From: juha.manninen62 at gmail.com (Juha Manninen) Date: Wed, 2 Aug 2017 17:50:11 +0300 Subject: [Lazarus] Status of namespace In-Reply-To: References: Message-ID: On Wed, Aug 2, 2017 at 5:46 PM, Juha Manninen wrote: > - The original bug is fixed long time ago, but I understood there are > 2 others that should be reported separately. > - F12 in designer. > - Codetools issues. ... and those may be fixed already, too. Juha From md at delfire.net Wed Aug 2 16:55:33 2017 From: md at delfire.net (Marcos Douglas B. Santos) Date: Wed, 2 Aug 2017 11:55:33 -0300 Subject: [Lazarus] Status of namespace In-Reply-To: References: Message-ID: On Wed, Aug 2, 2017 at 11:50 AM, Juha Manninen via Lazarus wrote: > On Wed, Aug 2, 2017 at 5:46 PM, Juha Manninen wrote: >> - The original bug is fixed long time ago, but I understood there are >> 2 others that should be reported separately. >> - F12 in designer. >> - Codetools issues. > > ... and those may be fixed already, too. I believe they were already fixed. I'm using it without these problems. Regards, Marcos Douglas From juha.manninen62 at gmail.com Wed Aug 2 21:39:22 2017 From: juha.manninen62 at gmail.com (Juha Manninen) Date: Wed, 2 Aug 2017 22:39:22 +0300 Subject: [Lazarus] Status of namespace In-Reply-To: References: Message-ID: On Wed, Aug 2, 2017 at 5:55 PM, Marcos Douglas B. Santos via Lazarus wrote: > I believe they were already fixed. I'm using it without these problems. Thanks. I was lazy to test myself now. Ondrej resolved the issue. The dotted names support may be quite perfect now. Juha From fluisgirardi at gmail.com Thu Aug 3 00:27:21 2017 From: fluisgirardi at gmail.com (Fabio Luis Girardi) Date: Wed, 2 Aug 2017 19:27:21 -0300 Subject: [Lazarus] Status of namespace In-Reply-To: References: Message-ID: Em 2 de ago de 2017 11:46 AM, "Juha Manninen" escreveu: No. Instead please work with them and report problems. I found 2 related bug reports: https://bugs.freepascal.org/view.php?id=24269 - FPDoc. May not be relevant in your case. (?) No. https://bugs.freepascal.org/view.php?id=20892 - The original bug is fixed long time ago, but I understood there are 2 others that should be reported separately. - F12 in designer. - Codetools issues. Can you please test and report the remaining issues. I will resolve #20892 then. My issues are related with Codetools. After insert a component or a control where the class is declared on dotted unit, I can't add a second component/control declared on other dotted unit. But I'll update my Lazarus first and then report my experiences. Thanks Fabio -------------- next part -------------- An HTML attachment was scrubbed... URL: From nc-gaertnma at netcologne.de Thu Aug 3 10:05:51 2017 From: nc-gaertnma at netcologne.de (Mattias Gaertner) Date: Thu, 3 Aug 2017 10:05:51 +0200 Subject: [Lazarus] Status of namespace In-Reply-To: References: Message-ID: <20170803100551.0e456e23@limapholos.matflo.wg> On Wed, 2 Aug 2017 22:39:22 +0300 Juha Manninen via Lazarus wrote: > On Wed, Aug 2, 2017 at 5:55 PM, Marcos Douglas B. Santos via Lazarus > wrote: > > I believe they were already fixed. I'm using it without these problems. > > Thanks. I was lazy to test myself now. > Ondrej resolved the issue. The dotted names support may be quite perfect now. In fact, even the -NS switch is supported by the IDE. So when eventually FPC supports it Lazarus is ready. Mattias From michael at freepascal.org Sat Aug 5 14:16:26 2017 From: michael at freepascal.org (Michael Van Canneyt) Date: Sat, 5 Aug 2017 14:16:26 +0200 (CEST) Subject: [Lazarus] High DPI ? Message-ID: Hello, I'm running lazarus on a high-dpi laptop. The laptop has a dual-boot Linux mint and Mac OS. I run Lazarus on both OS-es but I seriously doubt it has enabled HighDPI, because the icon buttons are still very small. How can I check that the IDE has actually enabled/activated HDPI and uses big icons/button images? Michael. From lazarus at kluug.net Sat Aug 5 14:47:42 2017 From: lazarus at kluug.net (Ondrej Pokorny) Date: Sat, 5 Aug 2017 14:47:42 +0200 Subject: [Lazarus] High DPI ? In-Reply-To: References: Message-ID: <742d2764-2a99-cd93-f130-3764f5ed534f@kluug.net> On 05.08.2017 14:16, Michael Van Canneyt via Lazarus wrote: > How can I check that the IDE has actually enabled/activated HDPI and uses > big icons/button images? Check for Application.Scaled := True in lazarus.pp. This enables Hi-DPI features. --- Another problem could be that the widgetset sends wrong PPI value to LCL. So check for Screen.PixelsPerInch (96 = 100%). If you build Lazarus with Gtk2, you could be affected by this WS-bug: https://mantis.freepascal.org/view.php?id=31199 Ondrej From michael at freepascal.org Sat Aug 5 15:39:12 2017 From: michael at freepascal.org (Michael Van Canneyt) Date: Sat, 5 Aug 2017 15:39:12 +0200 (CEST) Subject: [Lazarus] High DPI ? In-Reply-To: <742d2764-2a99-cd93-f130-3764f5ed534f@kluug.net> References: <742d2764-2a99-cd93-f130-3764f5ed534f@kluug.net> Message-ID: On Sat, 5 Aug 2017, Ondrej Pokorny via Lazarus wrote: > On 05.08.2017 14:16, Michael Van Canneyt via Lazarus wrote: >> How can I check that the IDE has actually enabled/activated HDPI and uses >> big icons/button images? > > Check for Application.Scaled := True in lazarus.pp. This enables Hi-DPI > features. I know that, I meant more 'how to verify the effects of this setting' :) Maybe I should have been more clear. > Another problem could be that the widgetset sends wrong PPI value to > LCL. So check for Screen.PixelsPerInch (96 = 100%). If you build Lazarus > with Gtk2, you could be affected by this WS-bug: > https://mantis.freepascal.org/view.php?id=31199 Thank you for the tip ! Since I have the same setup as the reporter I have applied the patch provided in this bugreport, and then HighDPI works on Linux. The buttons and images have a reasonable size, font looks normal... So, from my point of view, that patch can be applied ASAP :) Michael. From lazarus at kluug.net Sat Aug 5 16:08:45 2017 From: lazarus at kluug.net (Ondrej Pokorny) Date: Sat, 5 Aug 2017 16:08:45 +0200 Subject: [Lazarus] High DPI ? In-Reply-To: References: <742d2764-2a99-cd93-f130-3764f5ed534f@kluug.net> Message-ID: <46a51640-bd2c-0cb9-a4ab-fa4c0f78a776@kluug.net> On 05.08.2017 15:39, Michael Van Canneyt via Lazarus wrote: > Since I have the same setup as the reporter I have applied the patch > provided in this bugreport, and then HighDPI works on Linux. > The buttons and images have a reasonable size, font looks normal... > > So, from my point of view, that patch can be applied ASAP :) Thanks for the feedback - sometimes it's quite hard to get feedback from the reporters. I applied the patch. Ondrej From michael at freepascal.org Sat Aug 5 16:27:27 2017 From: michael at freepascal.org (Michael Van Canneyt) Date: Sat, 5 Aug 2017 16:27:27 +0200 (CEST) Subject: [Lazarus] High DPI ? In-Reply-To: <46a51640-bd2c-0cb9-a4ab-fa4c0f78a776@kluug.net> References: <742d2764-2a99-cd93-f130-3764f5ed534f@kluug.net> <46a51640-bd2c-0cb9-a4ab-fa4c0f78a776@kluug.net> Message-ID: On Sat, 5 Aug 2017, Ondrej Pokorny via Lazarus wrote: > On 05.08.2017 15:39, Michael Van Canneyt via Lazarus wrote: >> Since I have the same setup as the reporter I have applied the patch >> provided in this bugreport, and then HighDPI works on Linux. >> The buttons and images have a reasonable size, font looks normal... >> >> So, from my point of view, that patch can be applied ASAP :) > > Thanks for the feedback - sometimes it's quite hard to get feedback from > the reporters. I applied the patch. Thank you, it's a huge improvement ! Michael. From jmlandmesser at gmx.de Thu Aug 10 11:11:35 2017 From: jmlandmesser at gmx.de (John Landmesser) Date: Thu, 10 Aug 2017 11:11:35 +0200 Subject: [Lazarus] List down? Message-ID: just to see if my post will be shown on lazarus-ide.org because: *Last message date:*/Sat Aug 5 16:27:27 CEST 2017/ / / /... or just holiday? / -------------- next part -------------- An HTML attachment was scrubbed... URL: From wkitty42 at windstream.net Thu Aug 10 20:47:54 2017 From: wkitty42 at windstream.net (wkitty42 at windstream.net) Date: Thu, 10 Aug 2017 14:47:54 -0400 Subject: [Lazarus] List down? In-Reply-To: References: Message-ID: On 08/10/2017 05:11 AM, John Landmesser via Lazarus wrote: > just to see if my post will be shown on > > lazarus-ide.org > the list seems to be fine to me from waaaay over here... > because: > > *Last message date:*/Sat Aug 5 16:27:27 CEST 2017/ > > / > / > > /... or just holiday? > / but i do see the same wherein the last posts were on 5 Aug 2017... five of them... -- NOTE: No off-list assistance is given without prior approval. *Please keep mailing list traffic on the list unless* *a signed and pre-paid contract is in effect with us.* From donald at ziesig.org Thu Aug 10 20:49:08 2017 From: donald at ziesig.org (Donald Ziesig) Date: Thu, 10 Aug 2017 14:49:08 -0400 Subject: [Lazarus] List down? In-Reply-To: References: Message-ID: On 08/10/2017 02:47 PM, wkitty42--- via Lazarus wrote: > On 08/10/2017 05:11 AM, John Landmesser via Lazarus wrote: >> just to see if my post will be shown on >> >> lazarus-ide.org >> > > > the list seems to be fine to me from waaaay over here... > > >> because: >> >> *Last message date:*/Sat Aug 5 16:27:27 CEST 2017/ >> >> / >> / >> >> /... or just holiday? >> / > > > but i do see the same wherein the last posts were on 5 Aug 2017... > five of them... > > Likewise in Florida. Don Z. From r030t1 at gmail.com Fri Aug 11 05:33:50 2017 From: r030t1 at gmail.com (R0b0t1) Date: Thu, 10 Aug 2017 22:33:50 -0500 Subject: [Lazarus] List down? In-Reply-To: References: Message-ID: On Thu, Aug 10, 2017 at 4:11 AM, John Landmesser via Lazarus wrote: > just to see if my post will be shown on > > lazarus-ide.org > > > because: > > Last message date: Sat Aug 5 16:27:27 CEST 2017 > > > ... or just holiday? > The forums are far more active, and the developers seem to be fairly active on the forums if you need a response quickly. From friess at gmx.at Fri Aug 11 06:28:50 2017 From: friess at gmx.at (=?UTF-8?Q?Andreas_Frie=c3=9f?=) Date: Fri, 11 Aug 2017 06:28:50 +0200 Subject: [Lazarus] Status of namespace In-Reply-To: References: Message-ID: <7feeab59-3f68-f567-a464-ae0b21101062@gmx.at> Hi Fabio, i think, this is the Bug https://bugs.freepascal.org/view.php?id=32247 you mean. It is in also in Lazarus 1.8RC3 with akctual FPC trunk Andreas Am 03.08.2017 um 00:27 schrieb Fabio Luis Girardi via Lazarus: > > > Em 2 de ago de 2017 11:46 AM, "Juha Manninen" > > escreveu: > > > > No. Instead please work with them and report problems. > I found 2 related bug reports: > > https://bugs.freepascal.org/view.php?id=24269 > > - FPDoc. May not be relevant in your case. (?) > > > No. > > > https://bugs.freepascal.org/view.php?id=20892 > > - The original bug is fixed long time ago, but I understood there are > 2 others that should be reported separately. > - F12 in designer. > - Codetools issues. > Can you please test and report the remaining issues. I will > resolve #20892 then. > > > My issues are related with Codetools. After insert a component or a > control where the class is declared on dotted unit, I can't add a > second component/control declared on other dotted unit. But I'll > update my Lazarus first and then report my experiences. > > Thanks > > Fabio > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From friess at gmx.at Fri Aug 11 09:11:41 2017 From: friess at gmx.at (=?UTF-8?Q?Andreas_Frie=c3=9f?=) Date: Fri, 11 Aug 2017 09:11:41 +0200 Subject: [Lazarus] Reporting engine - What it's state? In-Reply-To: References: <559EC1C4.80108@yahoo.com> Message-ID: <30250fa8-3d84-e335-40e7-c36ace7638c7@gmx.at> Hi, pls, where can the actual 'unstable ?' Code found ? fpc trunk, where ? Thanks Andreas Am 24.07.2017 um 08:54 schrieb Michael Van Canneyt via Lazarus: > > > On Mon, 24 Jul 2017, Gabor Boros via Lazarus wrote: > >> Hi All, >> >> 2015. 07. 09. 21:45 keltezéssel, Michael Van Canneyt írta: >>> Just an opinion: >>> I am working with Graeme Geldenhuys to create a reporting engine >>> from scratch. >>> I think Lazreport's design contains some fundamental flaws, which >>> can only be remedied by re-implementing a reporting engine from >>> scratch. >> >> Two years gone. Any news? I see "In progress" on the Foundation's >> page, but want to know more detailed informations. >> >> https://foundation.freepascal.org/projects/reporting-engine > > It's ready and waiting for release. I'm waiting for 2 small fixes still: > - Some strange error when exporting a custom element to PDF > - Removing a dependency on freetype.dll on windows. > > Michael. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bo.berglund at gmail.com Sat Aug 12 06:42:06 2017 From: bo.berglund at gmail.com (Bo Berglund) Date: Sat, 12 Aug 2017 06:42:06 +0200 Subject: [Lazarus] List down? References: Message-ID: On Thu, 10 Aug 2017 22:33:50 -0500, R0b0t1 via Lazarus wrote: >The forums are far more active, and the developers seem to be fairly >active on the forums if you need a response quickly. Is there an NNTP interface (News) for the forums? I find the NNTP interface more useful than web browsing... In the case of the Lazarus and FPC mail lists GMane mirrors these as NNTP groups. -- Bo Berglund Developer in Sweden From michael at freepascal.org Sat Aug 12 11:03:30 2017 From: michael at freepascal.org (Michael Van Canneyt) Date: Sat, 12 Aug 2017 11:03:30 +0200 (CEST) Subject: [Lazarus] Reporting engine - What it's state? In-Reply-To: <30250fa8-3d84-e335-40e7-c36ace7638c7@gmx.at> References: <559EC1C4.80108@yahoo.com> <30250fa8-3d84-e335-40e7-c36ace7638c7@gmx.at> Message-ID: Hi, I will commit the code to FPC svn the coming week. Michael. On Fri, 11 Aug 2017, Andreas Frieß via Lazarus wrote: > Hi, > > pls, where can the actual 'unstable ?' Code found ? fpc trunk, where ? > > Thanks > Andreas > > Am 24.07.2017 um 08:54 schrieb Michael Van Canneyt via Lazarus: >> >> >> On Mon, 24 Jul 2017, Gabor Boros via Lazarus wrote: >> >>> Hi All, >>> >>> 2015. 07. 09. 21:45 keltezéssel, Michael Van Canneyt írta: >>>> Just an opinion: >>>> I am working with Graeme Geldenhuys to create a reporting engine from >>>> scratch. >>>> I think Lazreport's design contains some fundamental flaws, which can >>>> only be remedied by re-implementing a reporting engine from scratch. >>> >>> Two years gone. Any news? I see "In progress" on the Foundation's page, >>> but want to know more detailed informations. >>> >>> https://foundation.freepascal.org/projects/reporting-engine >> >> It's ready and waiting for release. I'm waiting for 2 small fixes still: >> - Some strange error when exporting a custom element to PDF >> - Removing a dependency on freetype.dll on windows. >> >> Michael. >> >> > > From wkitty42 at windstream.net Sat Aug 12 16:40:56 2017 From: wkitty42 at windstream.net (wkitty42 at windstream.net) Date: Sat, 12 Aug 2017 10:40:56 -0400 Subject: [Lazarus] List down? In-Reply-To: References: Message-ID: <4915eaae-52eb-6d82-7698-0dd8b2dc3bfe@windstream.net> On 08/12/2017 12:42 AM, Bo Berglund via Lazarus wrote: > On Thu, 10 Aug 2017 22:33:50 -0500, R0b0t1 via Lazarus wrote: > >> The forums are far more active, and the developers seem to be fairly >> active on the forums if you need a response quickly. > > Is there an NNTP interface (News) for the forums? no... there may be an RSS feed but i'm not sure of that... i generally don't mind forums but there are a few with interfaces that i just don't like... > I find the NNTP interface more useful than web browsing... i prefer email but news is ok... > In the case of the Lazarus and FPC mail lists GMane mirrors these as > NNTP groups. because they're converting the list emails into news postings... -- NOTE: No off-list assistance is given without prior approval. *Please keep mailing list traffic on the list unless* *a signed and pre-paid contract is in effect with us.* From md at delfire.net Sat Aug 12 21:46:09 2017 From: md at delfire.net (Marcos Douglas B. Santos) Date: Sat, 12 Aug 2017 16:46:09 -0300 Subject: [Lazarus] String vs WideString Message-ID: Hi, I have a "old" system that was coded in FPC 2.6.5. Today I had to change something in the code and now I need to update to FPC 3.0 and Lazarus 1.9. This system uses a COM object. I made a class to wrap the configuration. So, all string arguments in this class is WideString based. The SetLicence method will receive a WideString but the source is a "string". Look: Lib.SetLicense( IniFile.ReadString('TheLib', 'license', '') ); As you know, IniFile.ReadString returns a "string" and some internal conversion is happening and the licence is not valid anymore. If I put the licence as a string directly, it works: Lib.SetLicense( 'my_licence_here' ); How can I change my code to work properly using Ini files, strings and WideString? Best regards, Marcos Douglas From nc-gaertnma at netcologne.de Sat Aug 12 22:32:47 2017 From: nc-gaertnma at netcologne.de (Mattias Gaertner) Date: Sat, 12 Aug 2017 22:32:47 +0200 Subject: [Lazarus] String vs WideString In-Reply-To: References: Message-ID: <20170812223247.73330e02@limapholos.matflo.wg> On Sat, 12 Aug 2017 16:46:09 -0300 "Marcos Douglas B. Santos via Lazarus" wrote: >[...] > Lib.SetLicense( > IniFile.ReadString('TheLib', 'license', '') > ); What encoding has the ini file? Mattias From md at delfire.net Sat Aug 12 22:43:29 2017 From: md at delfire.net (Marcos Douglas B. Santos) Date: Sat, 12 Aug 2017 17:43:29 -0300 Subject: [Lazarus] String vs WideString In-Reply-To: <20170812223247.73330e02@limapholos.matflo.wg> References: <20170812223247.73330e02@limapholos.matflo.wg> Message-ID: On Sat, Aug 12, 2017 at 5:32 PM, Mattias Gaertner via Lazarus wrote: > On Sat, 12 Aug 2017 16:46:09 -0300 > "Marcos Douglas B. Santos via Lazarus" > wrote: > >>[...] >> Lib.SetLicense( >> IniFile.ReadString('TheLib', 'license', '') >> ); > > What encoding has the ini file? ANSI. A simple text file on Windows with only ANSI chars. But I'm so sorry Mattias, it was my fault. The program was reading the wrong file version (problem in paths...). It works now, but I have one question: What is the right way to code to do not see this warning? Warning: Implicit string type conversion from "AnsiString" to "WideString" Regards, Marcos Douglas From nc-gaertnma at netcologne.de Sat Aug 12 22:49:56 2017 From: nc-gaertnma at netcologne.de (Mattias Gaertner) Date: Sat, 12 Aug 2017 22:49:56 +0200 Subject: [Lazarus] String vs WideString In-Reply-To: References: <20170812223247.73330e02@limapholos.matflo.wg> Message-ID: <20170812224956.4e624b23@limapholos.matflo.wg> On Sat, 12 Aug 2017 17:43:29 -0300 "Marcos Douglas B. Santos via Lazarus" wrote: >[...] > > What encoding has the ini file? > > ANSI. A simple text file on Windows with only ANSI chars. Which one? Do you mean Windows CP-1252? >[...] > Warning: Implicit string type conversion from "AnsiString" to "WideString" Explicit type cast: Lib.SetLicense( WideString(IniFile.ReadString('TheLib', 'license', '')) ); Mattias From md at delfire.net Sat Aug 12 22:56:58 2017 From: md at delfire.net (Marcos Douglas B. Santos) Date: Sat, 12 Aug 2017 17:56:58 -0300 Subject: [Lazarus] String vs WideString In-Reply-To: <20170812224956.4e624b23@limapholos.matflo.wg> References: <20170812223247.73330e02@limapholos.matflo.wg> <20170812224956.4e624b23@limapholos.matflo.wg> Message-ID: On Sat, Aug 12, 2017 at 5:49 PM, Mattias Gaertner via Lazarus wrote: > On Sat, 12 Aug 2017 17:43:29 -0300 > "Marcos Douglas B. Santos via Lazarus" > wrote: > >>[...] >> > What encoding has the ini file? >> >> ANSI. A simple text file on Windows with only ANSI chars. > > Which one? Do you mean Windows CP-1252? Yes... But would it make any difference? >>[...] >> Warning: Implicit string type conversion from "AnsiString" to "WideString" > > Explicit type cast: > > Lib.SetLicense( > WideString(IniFile.ReadString('TheLib', 'license', '')) > ); Wow... everywhere? :( Regards, Marcos Douglas From fluisgirardi at gmail.com Sun Aug 13 00:10:27 2017 From: fluisgirardi at gmail.com (Fabio Luis Girardi) Date: Sat, 12 Aug 2017 19:10:27 -0300 Subject: [Lazarus] Status of namespace In-Reply-To: <7feeab59-3f68-f567-a464-ae0b21101062@gmx.at> References: <7feeab59-3f68-f567-a464-ae0b21101062@gmx.at> Message-ID: I'll try reproduce it in Lazarus 1.9... Em 11 de ago de 2017 01:28, "Andreas Frieß via Lazarus" < lazarus at lists.lazarus-ide.org> escreveu: > Hi Fabio, > > i think, this is the Bug https://bugs.freepascal.org/view.php?id=32247 > you mean. It is in also in Lazarus 1.8RC3 with akctual FPC trunk > > Andreas > > Am 03.08.2017 um 00:27 schrieb Fabio Luis Girardi via Lazarus: > > > > Em 2 de ago de 2017 11:46 AM, "Juha Manninen" > escreveu: > > > > No. Instead please work with them and report problems. > I found 2 related bug reports: > > https://bugs.freepascal.org/view.php?id=24269 > - FPDoc. May not be relevant in your case. (?) > > > No. > > > https://bugs.freepascal.org/view.php?id=20892 > - The original bug is fixed long time ago, but I understood there are > 2 others that should be reported separately. > - F12 in designer. > - Codetools issues. > Can you please test and report the remaining issues. I will resolve #20892 > then. > > > My issues are related with Codetools. After insert a component or a > control where the class is declared on dotted unit, I can't add a second > component/control declared on other dotted unit. But I'll update my Lazarus > first and then report my experiences. > > Thanks > > Fabio > > > > > > -- > _______________________________________________ > Lazarus mailing list > Lazarus at lists.lazarus-ide.org > https://lists.lazarus-ide.org/listinfo/lazarus > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bo.berglund at gmail.com Sun Aug 13 00:21:55 2017 From: bo.berglund at gmail.com (Bo Berglund) Date: Sun, 13 Aug 2017 00:21:55 +0200 Subject: [Lazarus] String vs WideString References: <20170812223247.73330e02@limapholos.matflo.wg> <20170812224956.4e624b23@limapholos.matflo.wg> Message-ID: <1ivuocdrq736eamemh6mp6h9old5omrssn@4ax.com> On Sat, 12 Aug 2017 17:56:58 -0300, "Marcos Douglas B. Santos via Lazarus" wrote: >> Which one? Do you mean Windows CP-1252? > >Yes... >But would it make any difference? I recently had a problem with an application that was converted from old string type to AnsiString and seemingly worked in the new Unicode environment. However, we received reports that it had failed in some Asian countries (Korea, China, Thailand) and upon checking it turned out that the data inside a string used as buffer was changed because of locale differences.... After switching out the affected variable declarations from AnsiString to RawByteString the application seemingly started to work again also on these locations. So AnsiString is not safe either.... And after this I have spent some time to totally rework the use of strings as buffers to instead use TBytes. Lots of work but guaranteed to not sneak in unexpected conversions. -- Bo Berglund Developer in Sweden From md at delfire.net Sun Aug 13 04:42:43 2017 From: md at delfire.net (Marcos Douglas B. Santos) Date: Sat, 12 Aug 2017 23:42:43 -0300 Subject: [Lazarus] String vs WideString In-Reply-To: <1ivuocdrq736eamemh6mp6h9old5omrssn@4ax.com> References: <20170812223247.73330e02@limapholos.matflo.wg> <20170812224956.4e624b23@limapholos.matflo.wg> <1ivuocdrq736eamemh6mp6h9old5omrssn@4ax.com> Message-ID: On Sat, Aug 12, 2017 at 7:21 PM, Bo Berglund via Lazarus wrote: > On Sat, 12 Aug 2017 17:56:58 -0300, "Marcos Douglas B. Santos via > Lazarus" wrote: > >>> Which one? Do you mean Windows CP-1252? >> >>Yes... >>But would it make any difference? > > I recently had a problem with an application that was converted from > old string type to AnsiString and seemingly worked in the new Unicode > environment. > However, we received reports that it had failed in some Asian > countries (Korea, China, Thailand) and upon checking it turned out > that the data inside a string used as buffer was changed because of > locale differences.... > > After switching out the affected variable declarations from AnsiString > to RawByteString the application seemingly started to work again also > on these locations. > > So AnsiString is not safe either.... > > And after this I have spent some time to totally rework the use of > strings as buffers to instead use TBytes. Lots of work but guaranteed > to not sneak in unexpected conversions. Is not simpler to use RawByteString instead TBytes? Regards, Marcos Douglas From bo.berglund at gmail.com Sun Aug 13 11:19:35 2017 From: bo.berglund at gmail.com (Bo Berglund) Date: Sun, 13 Aug 2017 11:19:35 +0200 Subject: [Lazarus] String vs WideString References: <20170812223247.73330e02@limapholos.matflo.wg> <20170812224956.4e624b23@limapholos.matflo.wg> <1ivuocdrq736eamemh6mp6h9old5omrssn@4ax.com> Message-ID: <4360pc5huuj7gc8qjq3vk0cdf3jj06q9b8@4ax.com> On Sat, 12 Aug 2017 23:42:43 -0300, "Marcos Douglas B. Santos via Lazarus" wrote: >> After switching out the affected variable declarations from AnsiString >> to RawByteString the application seemingly started to work again also >> on these locations. >> >> So AnsiString is not safe either.... >> >> And after this I have spent some time to totally rework the use of >> strings as buffers to instead use TBytes. Lots of work but guaranteed >> to not sneak in unexpected conversions. > >Is not simpler to use RawByteString instead TBytes? Well, initially just changing the declarations would seem to be simpler. But given how the conversion problem sneaked up behind my back, I thought it wiser to move all serial comm buffers from various string types (string->AnsiString->RawByteString) to TBytes since that is really guaranteed to be "the real thing". Whenever there is a need for displaying the data or putting them into a string type variable I have added a few utility functions to do the conversions using the Move() procedure. Likewise I made a PosBin() for searching for patterns like Pos() for strings etc. -- Bo Berglund Developer in Sweden From mailinglists at geldenhuys.co.uk Sun Aug 13 12:18:04 2017 From: mailinglists at geldenhuys.co.uk (Graeme Geldenhuys) Date: Sun, 13 Aug 2017 11:18:04 +0100 Subject: [Lazarus] Status of namespace In-Reply-To: References: Message-ID: On 2017-08-02 20:39, Juha Manninen via Lazarus wrote: > he dotted names support may be quite perfect now. So does FPC or Lazarus already support the ability to specify the default namespace that must be applied for a project? If so how and where do you specify the namespace to be applied? eg: With Delphi I can write code using the Forms unit, but then at compile time I can specify the VCL or FMX namespace, and the correct .Forms.pas unit will be used. This is a key feature of namespaces and dotted units - and very useful in framework type code. Last time I checked [some months ago] FPC and Lazarus only supported dotted unit names, but the ability to specify a default namespace was not supported yet. 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 From pascaldragon at googlemail.com Sun Aug 13 12:44:44 2017 From: pascaldragon at googlemail.com (Sven Barth) Date: Sun, 13 Aug 2017 12:44:44 +0200 Subject: [Lazarus] Status of namespace In-Reply-To: References: Message-ID: Am 13.08.2017 12:18 schrieb "Graeme Geldenhuys via Lazarus" < lazarus at lists.lazarus-ide.org>: > > On 2017-08-02 20:39, Juha Manninen via Lazarus wrote: >> >> he dotted names support may be quite perfect now. > > > So does FPC or Lazarus already support the ability to specify the default namespace that must be applied for a project? If so how and where do you specify the namespace to be applied? > > eg: > With Delphi I can write code using the Forms unit, but then at compile time I can specify the VCL or FMX namespace, and the correct .Forms.pas unit will be used. This is a key feature of namespaces and dotted units - and very useful in framework type code. > > Last time I checked [some months ago] FPC and Lazarus only supported dotted unit names, but the ability to specify a default namespace was not supported yet. Specifying default namespaces (yes, plural) is not yet supported by FPC. Regards, Sven -------------- next part -------------- An HTML attachment was scrubbed... URL: From juha.manninen62 at gmail.com Sun Aug 13 12:51:19 2017 From: juha.manninen62 at gmail.com (Juha Manninen) Date: Sun, 13 Aug 2017 13:51:19 +0300 Subject: [Lazarus] String vs WideString In-Reply-To: <1ivuocdrq736eamemh6mp6h9old5omrssn@4ax.com> References: <20170812223247.73330e02@limapholos.matflo.wg> <20170812224956.4e624b23@limapholos.matflo.wg> <1ivuocdrq736eamemh6mp6h9old5omrssn@4ax.com> Message-ID: On Sun, Aug 13, 2017 at 1:21 AM, Bo Berglund via Lazarus wrote: > So AnsiString is not safe either.... That is a little misleading. Actually using the Windows system codepage is not safe any more. The current Unicode system in Lazarus maps AnsiString to use UTF-8. Text with Windows codepage must be converted explicitly. This is a breaking change compared to the old Unicode suppport in Lazarus 1.4.x + FPC 2.6.x. The right solution is to use Unicode everywhere. Windows codepages can be seen as a historical remain, retained for backwards compatibility. Now is year 2017, Unicode has been used for decades. Everybody should use it by now. Marcos Douglas, please change the encoding in your text file to UTF-8. Every decent text editor, including the editor in Lazarus, has a feature to do it. Once the data is Unicode, it is all smooth sailing. Data is converted between UTF-8 and UTF-16 losslessly. One more thing: Data for WideString/UnicodeString parameters in WinAPI functions are converted automatically. You can ignore the warning or suppress it by a type cast as Mattias showed. However for PWideChar parameters you should create an explicit temporary variable, usually UnicodeString but WideString for OLE. Assigning to it from your "String" data converts encoding. Then cast the new variable as the required pointer type. Juha From juha.manninen62 at gmail.com Sun Aug 13 13:18:23 2017 From: juha.manninen62 at gmail.com (Juha Manninen) Date: Sun, 13 Aug 2017 14:18:23 +0300 Subject: [Lazarus] String vs WideString In-Reply-To: <1ivuocdrq736eamemh6mp6h9old5omrssn@4ax.com> References: <20170812223247.73330e02@limapholos.matflo.wg> <20170812224956.4e624b23@limapholos.matflo.wg> <1ivuocdrq736eamemh6mp6h9old5omrssn@4ax.com> Message-ID: On Sun, Aug 13, 2017 at 1:21 AM, Bo Berglund via Lazarus wrote: > I recently had a problem with an application that was converted from > old string type to AnsiString and seemingly worked in the new Unicode > environment. What was the old string type? > However, we received reports that it had failed in some Asian > countries (Korea, China, Thailand) and upon checking it turned out > that the data inside a string used as buffer was changed because of > locale differences.... Unicode was designed to solve exactly the problems caused by locale differences. Why don't you use it? > After switching out the affected variable declarations from AnsiString > to RawByteString the application seemingly started to work again also > on these locations. > ... > And after this I have spent some time to totally rework the use of > strings as buffers to instead use TBytes. Lots of work but > guaranteed to not sneak in unexpected conversions. RawByteString is for text which encoding is not meant to be converted. It has its special use cases. TBytes is usually for binary data. Did I understand right: you use TBytes to hold strings having Windows codepage encoding? That sounds like a very dummy thing to do! Again: Why not Unicode? Then you could throw away your hacks. Juha From bo.berglund at gmail.com Sun Aug 13 18:41:09 2017 From: bo.berglund at gmail.com (Bo Berglund) Date: Sun, 13 Aug 2017 18:41:09 +0200 Subject: [Lazarus] String vs WideString References: <20170812223247.73330e02@limapholos.matflo.wg> <20170812224956.4e624b23@limapholos.matflo.wg> <1ivuocdrq736eamemh6mp6h9old5omrssn@4ax.com> Message-ID: <1dv0pc11iiibf5mavq8v9lrdgnnmubrmgj@4ax.com> On Sun, 13 Aug 2017 14:18:23 +0300, Juha Manninen via Lazarus wrote: >On Sun, Aug 13, 2017 at 1:21 AM, Bo Berglund via Lazarus > wrote: >> I recently had a problem with an application that was converted from >> old string type to AnsiString and seemingly worked in the new Unicode >> environment. > >What was the old string type? Note: The programs were started back in around 2000 using Delphi 7... We used "string" as the container for processing serial data to/from CNC machine tool controllers amongst others. This was triggered really by the serial components, which mostly transferred char(acters) and had methods for sending and receiving strings, even though we usually used char. >> However, we received reports that it had failed in some Asian >> countries (Korea, China, Thailand) and upon checking it turned out >> that the data inside a string used as buffer was changed because of >> locale differences.... > >Unicode was designed to solve exactly the problems caused by locale differences. >Why don't you use it? Again, these are old existing programs and we are not doing this anymore for new programs. However, there is one problem still becauyse there is an interface point to the hardware, in the form of serial components, which still handle chars... And chars are nowadays Unicode chars, i.e. not mapping to bytes sent by RS232... And our data are NOT text, they are binary streams of bytes. >> After switching out the affected variable declarations from AnsiString >> to RawByteString the application seemingly started to work again also >> on these locations. >> ... >> And after this I have spent some time to totally rework the use of >> strings as buffers to instead use TBytes. Lots of work but >> guaranteed to not sneak in unexpected conversions. > >RawByteString is for text which encoding is not meant to be converted. >It has its special use cases. My first attempt at "fixing" the problem in Asian locales was to use RawByteString so as to inhibit conversions. Still with these as comm buffers... It seemed to work out, but to be safer I have reworked one application to replace with TBytes everywhere comm data are handled. >TBytes is usually for binary data. Exactly, and this is why I made the comment that to be on the safe side dealing with RS232 the buffers should be TBytes (or some other similar construct). >Did I understand right: you use TBytes to hold strings having Windows >codepage encoding? No, definitively not. At the time we were not aware of any encoding at all. To us a string was just a handy container for the serial data like a dynamic array of byte with some useful functions available for searching and things like that. I think we were not alone... >Again: Why not Unicode? Then you could throw away your hacks. The application itself is Unicode now but we had to run circles around the RS232 comm part. When converting to Unicode we first set the comm related strings to be AnsiString... PS: We never programmed the serial interface directly, we always used commercial RS232 components and they all dealt with char and string... DS -- Bo Berglund Developer in Sweden From nc-gaertnma at netcologne.de Sun Aug 13 21:21:28 2017 From: nc-gaertnma at netcologne.de (Mattias Gaertner) Date: Sun, 13 Aug 2017 21:21:28 +0200 Subject: [Lazarus] Lazarus Release Candidate 4 of 1.8.0 Message-ID: <20170813212128.30e0a6c7@limapholos.matflo.wg> The Lazarus team is glad to announce the fourth release candidate of Lazarus 1.8. This release was built with FPC 3.0.4RC1, except for Mac OS, which still uses 3.0.2. The previous release Lazarus 1.6.4 was built with FPC 3.0.2. https://bugs.freepascal.org/view.php?id=31629 Here is the list of fixes for Lazarus 1.8.x: http://wiki.freepascal.org/Lazarus_1.8_fixes_branch Here is the list of changes for Lazarus and Free Pascal: http://wiki.lazarus.freepascal.org/Lazarus_1.8.0_release_notes http://wiki.lazarus.freepascal.org/User_Changes_3.0.4 The release is available for download on SourceForge: http://sourceforge.net/projects/lazarus/files/ Choose your CPU, OS, distro and then the "Lazarus 1.8 RC4" directory. Checksums for the SourceForge files: http://www.lazarus-ide.org/index.php?page=checksums#1_8_0RC4 Minimum requirements: Windows: 2k, XP, Vista, 7, 8, 8.1 and 10, 32 or 64bit. FreeBSD/Linux: gtk 2.8 for gtk2, qt4.5 for qt, qt5.6 for qt5, 32 or 64bit. Mac OS X: 10.5 to 10.12; Carbon (32bit), Cocoa (64bit, not stable), qt and qt5 (32 or 64bit). The svn tag is http://svn.freepascal.org/svn/lazarus/tags/lazarus_1_8_0_RC4 For people who are blocked by SF, the Lazarus releases from SourceForge are mirrored at: ftp://ftp.freepascal.org/pub/lazarus/releases/ and later at (after some time for synchronization) http://mirrors.iwi.me/lazarus/ == Why should everybody (including you) test the release candidate? == In the past weeks the Lazarus team has stabilized the 1.8 fixes branch. The resulting 1.8RC4 is now stable enough to be used by any one for test purposes. However many of the fixes and new features that where committed since the release of 1.6 required changes to the code of existing features too. While we have tested those ourself, there may still be problems that only occur with very specific configurations or one project in a million. Yes, it may be that you are the only person with a project, that will not work in the new IDE. So if you do not test, we can not fix it. Please do not wait for the final release, in order to test. It may be too late. Once the release is out we will have to be more selective about which fixes can be merged for further 1.8.x releases. So it may be, that we can not merge the fix you require. And then you will miss out on all the new features. == How to test == Download and install the 1.8 RC4. - On Windows you can install as a 2ndary install, that will not affect your current install: http://wiki.lazarus.freepascal.org/Multiple_Lazarus#Installation_of_multiple_Lazarus - On other platforms, if you install to a new location you need to use --primary-config-path In either case you should make backups. (including your primary config) Open your project in the current Lazarus (1.6.x), and use "Publish Project" from the project menu. This creates a clean copy of your project. You can then open that copy in the RC4. Please test: - If you can edit forms in the designer - rename components / change properties in Object inspector / Add new events - Add components to form / Move components on form - Frames, if you use them - If you can navigate the source code (e.g. jump to implementation) - Auto completion in source code - Compile, debug and run - Anything else you use in your daily work Mattias From juha.manninen62 at gmail.com Sun Aug 13 22:41:34 2017 From: juha.manninen62 at gmail.com (Juha Manninen) Date: Sun, 13 Aug 2017 23:41:34 +0300 Subject: [Lazarus] String vs WideString In-Reply-To: <1dv0pc11iiibf5mavq8v9lrdgnnmubrmgj@4ax.com> References: <20170812223247.73330e02@limapholos.matflo.wg> <20170812224956.4e624b23@limapholos.matflo.wg> <1ivuocdrq736eamemh6mp6h9old5omrssn@4ax.com> <1dv0pc11iiibf5mavq8v9lrdgnnmubrmgj@4ax.com> Message-ID: On Sun, Aug 13, 2017 at 7:41 PM, Bo Berglund via Lazarus wrote: > And our data are NOT text, they are binary streams of bytes. I see. Then TBytes indeed is the best choice. You have misused "String" or "AnsiString" from the beginning for binary data. There have always been warnings against it. The new Lazarus Unicode system did not create the problem but made it more visible. Marcos Douglas however has a different problem. Your recommendation to use RawByteString or TBytes does not apply in his case and thus was a bit misleading. Juha From mschnell at lumino.de Mon Aug 14 10:25:14 2017 From: mschnell at lumino.de (Michael Schnell) Date: Mon, 14 Aug 2017 10:25:14 +0200 Subject: [Lazarus] String vs WideString In-Reply-To: References: <20170812223247.73330e02@limapholos.matflo.wg> <20170812224956.4e624b23@limapholos.matflo.wg> <1ivuocdrq736eamemh6mp6h9old5omrssn@4ax.com> <1dv0pc11iiibf5mavq8v9lrdgnnmubrmgj@4ax.com> Message-ID: <454f20e8-f630-11c6-ff64-6aa255fc8db0@lumino.de> On 13.08.2017 22:41, Juha Manninen via Lazarus wrote: > You have misused "String" or "AnsiString" from the beginning for binary data. > There have always been warnings against it. While this might be true, it's decently silly, IMHO. The name "String" can easily be interpreted as "String of things" and does not necessarily mean "String of printable stuff". The management Pascal always provided for strings (after the "Short String" was not the only string type) (i.e. Operators, built-in functions, lazy copy, reference counting) is perfectly applicable to "Strings of things", and don't force any known encoding at all. The drama only was introduced by Embarcadero's abysmal / sloppy implementation of automatic code conversion for strings. -Michael From tony.whyman at mccallumwhyman.com Mon Aug 14 11:53:44 2017 From: tony.whyman at mccallumwhyman.com (Tony Whyman) Date: Mon, 14 Aug 2017 10:53:44 +0100 Subject: [Lazarus] String vs WideString In-Reply-To: References: <20170812223247.73330e02@limapholos.matflo.wg> <20170812224956.4e624b23@limapholos.matflo.wg> <1ivuocdrq736eamemh6mp6h9old5omrssn@4ax.com> Message-ID: <38b0193a-eb86-4d6a-6292-f2203daff126@mccallumwhyman.com> On 13/08/17 12:18, Juha Manninen via Lazarus wrote: > Unicode was designed to solve exactly the problems caused by locale differences. > Why don't you use it? I believe you effectively answer your own question in your preceding post: > Actually using the Windows system codepage is not safe any more. > The current Unicode system in Lazarus maps AnsiString to use UTF-8. > Text with Windows codepage must be converted explicitly. > This is a breaking change compared to the old Unicode suppport in > Lazarus 1.4.x + FPC 2.6.x. If you are processing strings as "text" then you probably do not care how it is encoded and can live with "breaking changes". However, if, for some reason you are or need to be aware of how the text is encoded - or are using string types as a useful container for binary data then, types that sneak up on you with implicit type conversions or which have semantics that change between compilers or versions, are just another source of bugs. PChar used to be a safe means to access binary data - but not anymore, especially if you move between FPC and Delphi. (One of my gripes is that the FCL still makes too much use of PChar instead of PByte with the resulting Delphi incompatibility). The "string" type also used to be a safe container for any sort of binary data, but when its definition can change between compilers and versions, it is now something to be avoided. As a general rule, I now always use PByte for any sort of string that is binary, untyped or encoding to be determined. It works across compilers (FPC and Delphi) with consistent semantics and is safe for such use. I also really like AnsiString from FCP 3.0 onwards. By making the encoding a dynamic attribute of the type, it means that I know what is in the container and can keep control. I am sorry, but I would only even consider using Unicodestrings as a type (or the default string type) when I am just processing text for which the encoding is a don't care, such as a window caption, or for intensive text analysis. If I am reading/writing text from a file or database where the encoding is often implicit and may vary from the Unicode standard then my preference is for AnsiString. I can then read the text (e.g. from the file) into a (RawByteString) buffer, set the encoding and then process it safely while often avoiding the overhead from any transliteration. PByte comes into its own when the file contains a mixture of binary data and text. Text files and databases tend to use UTF-8 or are encoded using legacy Windows Code pages. The Chinese also have GB18030. With a database, the encoding is usually known and AnsiString is a good way to read/write data and to convey the encoding, especially as databases usually use a variable length multi-byte encoding natively and not UTF-16/Unicode. With files, the text encoding is usually implicit and AnsiString is ideal for this as it lets you read in the text and then assign the (implicit) encoding to the string, or ensure the correct encoding when writing. And anyway, I do most of my work in Linux, so why would I even want to bother myself with arrays of widechars when the default environment is UTF8? We do need some stability and consistency in strings which, as someone else noted have been confused by Embarcadero. I would like to see that focused on AnsiString with UnicodeString being only for specialist use on Windows or when intensive text analysis makes a two byte encoding more efficient than a variable length multi-byte encoding. Tony Whyman MWA From mailinglists at geldenhuys.co.uk Mon Aug 14 14:25:12 2017 From: mailinglists at geldenhuys.co.uk (Graeme Geldenhuys) Date: Mon, 14 Aug 2017 13:25:12 +0100 Subject: [Lazarus] Status of namespace In-Reply-To: References: Message-ID: <4196b354-fb72-853f-f54d-a047cbeb5639@geldenhuys.co.uk> On 2017-08-13 11:44, Sven Barth via Lazarus wrote: > Specifying default namespaces (yes, plural) is not yet supported by FPC. Okay, thanks for confirming that Sven. Regards, Graeme From md at delfire.net Mon Aug 14 14:50:23 2017 From: md at delfire.net (Marcos Douglas B. Santos) Date: Mon, 14 Aug 2017 09:50:23 -0300 Subject: [Lazarus] String vs WideString In-Reply-To: References: <20170812223247.73330e02@limapholos.matflo.wg> <20170812224956.4e624b23@limapholos.matflo.wg> <1ivuocdrq736eamemh6mp6h9old5omrssn@4ax.com> Message-ID: On Sun, Aug 13, 2017 at 7:51 AM, Juha Manninen via Lazarus wrote: > On Sun, Aug 13, 2017 at 1:21 AM, Bo Berglund via Lazarus > wrote: >> So AnsiString is not safe either.... > > That is a little misleading. > Actually using the Windows system codepage is not safe any more. > The current Unicode system in Lazarus maps AnsiString to use UTF-8. > Text with Windows codepage must be converted explicitly. > This is a breaking change compared to the old Unicode suppport in > Lazarus 1.4.x + FPC 2.6.x. > The right solution is to use Unicode everywhere. Windows codepages can > be seen as a historical remain, retained for backwards compatibility. > Now is year 2017, Unicode has been used for decades. Everybody should > use it by now. "The right solution is to use Unicode everywhere." I agree. But would be best if the compiler uses Unicode everywhere and us, developers, using just one type called "string"... Even if this break the old code. Maybe, instead using "string", the new code should be use just UnicodeString... Well, I know that many people here already had this "fight" about Unicode so, let's forget about it what the compiler "should" or not to do. > Marcos Douglas, please change the encoding in your text file to UTF-8. > Every decent text editor, including the editor in Lazarus, has a > feature to do it. > Once the data is Unicode, it is all smooth sailing. > Data is converted between UTF-8 and UTF-16 losslessly. You're right. > One more thing: > Data for WideString/UnicodeString parameters in WinAPI functions are > converted automatically. You can ignore the warning or suppress it by > a type cast as Mattias showed. > However for PWideChar parameters you should create an explicit > temporary variable, usually UnicodeString but WideString for OLE. > Assigning to it from your "String" data converts encoding. > Then cast the new variable as the required pointer type. This is a ugly trick... but I understood what you mean. Best regards, Marcos Douglas From md at delfire.net Mon Aug 14 15:11:27 2017 From: md at delfire.net (Marcos Douglas B. Santos) Date: Mon, 14 Aug 2017 10:11:27 -0300 Subject: [Lazarus] String vs WideString In-Reply-To: <38b0193a-eb86-4d6a-6292-f2203daff126@mccallumwhyman.com> References: <20170812223247.73330e02@limapholos.matflo.wg> <20170812224956.4e624b23@limapholos.matflo.wg> <1ivuocdrq736eamemh6mp6h9old5omrssn@4ax.com> <38b0193a-eb86-4d6a-6292-f2203daff126@mccallumwhyman.com> Message-ID: On Mon, Aug 14, 2017 at 6:53 AM, Tony Whyman via Lazarus wrote: > > On 13/08/17 12:18, Juha Manninen via Lazarus wrote: >> >> Unicode was designed to solve exactly the problems caused by locale >> differences. >> Why don't you use it? > > I believe you effectively answer your own question in your preceding post: > >> Actually using the Windows system codepage is not safe any more. >> The current Unicode system in Lazarus maps AnsiString to use UTF-8. >> Text with Windows codepage must be converted explicitly. >> This is a breaking change compared to the old Unicode suppport in >> Lazarus 1.4.x + FPC 2.6.x. > > If you are processing strings as "text" then you probably do not care how it > is encoded and can live with "breaking changes". However, if, for some > reason you are or need to be aware of how the text is encoded - or are using > string types as a useful container for binary data then, types that sneak up > on you with implicit type conversions or which have semantics that change > between compilers or versions, are just another source of bugs. > > PChar used to be a safe means to access binary data - but not anymore, > especially if you move between FPC and Delphi. (One of my gripes is that the > FCL still makes too much use of PChar instead of PByte with the resulting > Delphi incompatibility). The "string" type also used to be a safe container > for any sort of binary data, but when its definition can change between > compilers and versions, it is now something to be avoided. > > As a general rule, I now always use PByte for any sort of string that is > binary, untyped or encoding to be determined. It works across compilers (FPC > and Delphi) with consistent semantics and is safe for such use. > > I also really like AnsiString from FCP 3.0 onwards. By making the encoding a > dynamic attribute of the type, it means that I know what is in the container > and can keep control. > > I am sorry, but I would only even consider using Unicodestrings as a type > (or the default string type) when I am just processing text for which the > encoding is a don't care, such as a window caption, or for intensive text > analysis. If I am reading/writing text from a file or database where the > encoding is often implicit and may vary from the Unicode standard then my > preference is for AnsiString. I can then read the text (e.g. from the file) > into a (RawByteString) buffer, set the encoding and then process it safely > while often avoiding the overhead from any transliteration. PByte comes into > its own when the file contains a mixture of binary data and text. > > Text files and databases tend to use UTF-8 or are encoded using legacy > Windows Code pages. The Chinese also have GB18030. With a database, the > encoding is usually known and AnsiString is a good way to read/write data > and to convey the encoding, especially as databases usually use a variable > length multi-byte encoding natively and not UTF-16/Unicode. With files, the > text encoding is usually implicit and AnsiString is ideal for this as it > lets you read in the text and then assign the (implicit) encoding to the > string, or ensure the correct encoding when writing. Unicode everywhere and you using AnsiString and doing everything... Now I'm confused. > And anyway, I do most of my work in Linux, so why would I even want to > bother myself with arrays of widechars when the default environment is UTF8? Maybe you do not have problems because you don't use Windows. > We do need some stability and consistency in strings which, as someone else > noted have been confused by Embarcadero. I would like to see that focused on > AnsiString with UnicodeString being only for specialist use on Windows or > when intensive text analysis makes a two byte encoding more efficient than a > variable length multi-byte encoding. FPC and Lazarus claim they are cross-platform — this is a fact — and because that, IMHO, both should be use in only one way in every system, don't you think? Best regards, Marcos Douglas From mschnell at lumino.de Mon Aug 14 15:19:05 2017 From: mschnell at lumino.de (Michael Schnell) Date: Mon, 14 Aug 2017 15:19:05 +0200 Subject: [Lazarus] String vs WideString In-Reply-To: References: <20170812223247.73330e02@limapholos.matflo.wg> <20170812224956.4e624b23@limapholos.matflo.wg> <1ivuocdrq736eamemh6mp6h9old5omrssn@4ax.com> Message-ID: On 14.08.2017 14:50, Marcos Douglas B. Santos via Lazarus wrote: > > "The right solution is to use Unicode everywhere." Embarcadero though that this would not b the "right" solution. Otherwise they would not have invented the encoding aware strings. IMHO that was a good idea. They only completely failed to do a decent specification and implementation. -Michael From tony.whyman at mccallumwhyman.com Mon Aug 14 15:21:57 2017 From: tony.whyman at mccallumwhyman.com (Tony Whyman) Date: Mon, 14 Aug 2017 14:21:57 +0100 Subject: [Lazarus] String vs WideString In-Reply-To: References: <20170812223247.73330e02@limapholos.matflo.wg> <20170812224956.4e624b23@limapholos.matflo.wg> <1ivuocdrq736eamemh6mp6h9old5omrssn@4ax.com> <38b0193a-eb86-4d6a-6292-f2203daff126@mccallumwhyman.com> Message-ID: On 14/08/17 14:11, Marcos Douglas B. Santos via Lazarus wrote: > FPC and Lazarus claim they are cross-platform — this is a fact — and > because that, IMHO, both should be use in only one way in every > system, don't you think? > > Best regards, > Marcos Douglas Precisely. But why this fixation on UTF-16/Unicode and not UTF8? Lazarus is already a UTF8 environment. Much of the LCL assumes UTF8. UTF8 is arguably a much more efficient way to store and transfer data UTF-16/Unicode can only store 65,536 characters while the Unicode standard (that covers UTF8 as well) defines 136,755 characters. UTF-16/Unicode's main advantage seems to be for rapid indexing of large strings. You made need UTF-16/Unicode support for accessing Microsoft APIs but apart from that, why is it being promoted as the universal standard? From nc-gaertnma at netcologne.de Mon Aug 14 15:46:54 2017 From: nc-gaertnma at netcologne.de (Mattias Gaertner) Date: Mon, 14 Aug 2017 15:46:54 +0200 Subject: [Lazarus] String vs WideString In-Reply-To: References: <20170812223247.73330e02@limapholos.matflo.wg> <20170812224956.4e624b23@limapholos.matflo.wg> <1ivuocdrq736eamemh6mp6h9old5omrssn@4ax.com> <38b0193a-eb86-4d6a-6292-f2203daff126@mccallumwhyman.com> Message-ID: <20170814154654.52d5d1d4@limapholos.matflo.wg> On Mon, 14 Aug 2017 14:21:57 +0100 Tony Whyman via Lazarus wrote: >[...] > Lazarus is already a UTF8 environment. > > Much of the LCL assumes UTF8. True. > UTF8 is arguably a much more efficient way to store and transfer data It depends. > UTF-16/Unicode can only store 65,536 characters while the Unicode > standard (that covers UTF8 as well) defines 136,755 characters. No. UTF-16 can encode the full 1 million Unicode range. It uses one or two words per codepoint. UTF-8 uses 1 to 4 bytes. See here for more details: https://en.wikipedia.org/wiki/UTF-16 Although you are right, that there are still many applications, that falsely claim to support UTF-16, but only support the first $D800 codepoints. > UTF-16/Unicode's main advantage seems to be for rapid indexing of large > strings. That's only true for UCS-2, which is obsolete. > You made need UTF-16/Unicode support for accessing Microsoft APIs but > apart from that, why is it being promoted as the universal standard? Who does that? Mattias From mailinglists at geldenhuys.co.uk Mon Aug 14 15:55:47 2017 From: mailinglists at geldenhuys.co.uk (Graeme Geldenhuys) Date: Mon, 14 Aug 2017 14:55:47 +0100 Subject: [Lazarus] String vs WideString In-Reply-To: References: <20170812223247.73330e02@limapholos.matflo.wg> <20170812224956.4e624b23@limapholos.matflo.wg> <1ivuocdrq736eamemh6mp6h9old5omrssn@4ax.com> Message-ID: <4e60c263-bbfb-802c-0939-5efdaed346af@geldenhuys.co.uk> On 2017-08-13 11:51, Juha Manninen via Lazarus wrote: > Now is year 2017, Unicode has been used for decades. Everybody should > use it by now. Indeed, I can't agree more. Plus, I normally use UTF-8 for any text files I create. Regards, Graeme From tony.whyman at mccallumwhyman.com Mon Aug 14 16:11:15 2017 From: tony.whyman at mccallumwhyman.com (Tony Whyman) Date: Mon, 14 Aug 2017 15:11:15 +0100 Subject: [Lazarus] String vs WideString In-Reply-To: <20170814154654.52d5d1d4@limapholos.matflo.wg> References: <20170812223247.73330e02@limapholos.matflo.wg> <20170812224956.4e624b23@limapholos.matflo.wg> <1ivuocdrq736eamemh6mp6h9old5omrssn@4ax.com> <38b0193a-eb86-4d6a-6292-f2203daff126@mccallumwhyman.com> <20170814154654.52d5d1d4@limapholos.matflo.wg> Message-ID: On 14/08/17 14:46, Mattias Gaertner via Lazarus wrote: >> You made need UTF-16/Unicode support for accessing Microsoft APIs but >> apart from that, why is it being promoted as the universal standard? > Who does that? > > Mattias Because the obvious implication when someone argues against AnsiString (from which UTF8String derives) and talks about Unicode is that they are promoting UTF-16 and the UnicodeString type. Perhaps this is because I am old enough to remember when MS first added wide characters to Windows and that they called it "Unicode". To me, when people say "Unicode" they mean Windows wide characters. Perhaps the problem is the use of the word "Unicode". By trying to embrace UTF8, UTF16 and UTF32 with the older UCS-2 it is perhaps too ambiguous a term - especially as the Delphi/FPC UnicodeString type exists and probably (but I'm not certain) means UTF-16. What I see in FPC/Lazarus today is: - UTF8 supported through AnsiString. - A confusion of Widestring/UnicodeString for UTF-16 and legacy UCS-2. - Nothing for UTF-32. If nothing else, FPC Lazarus could do with a clean-up of both terminology and string types. Indeed, why isn't there a single container string type for all character sets where the encoding whether a legacy code page, UTF8, UTF16 or UTF32 is simply a dynamic attribute of the type - a sort of extended AnsiString? -------------- next part -------------- An HTML attachment was scrubbed... URL: From mailinglists at geldenhuys.co.uk Mon Aug 14 16:20:52 2017 From: mailinglists at geldenhuys.co.uk (Graeme Geldenhuys) Date: Mon, 14 Aug 2017 15:20:52 +0100 Subject: [Lazarus] String vs WideString In-Reply-To: References: <20170812223247.73330e02@limapholos.matflo.wg> <20170812224956.4e624b23@limapholos.matflo.wg> <1ivuocdrq736eamemh6mp6h9old5omrssn@4ax.com> <38b0193a-eb86-4d6a-6292-f2203daff126@mccallumwhyman.com> <20170814154654.52d5d1d4@limapholos.matflo.wg> Message-ID: <70ad8658-8284-2c33-6604-3afe0eef5311@geldenhuys.co.uk> On 2017-08-14 15:11, Tony Whyman via Lazarus wrote: > ambiguous a term - especially as the Delphi/FPC UnicodeString type > exists and probably (but I'm not certain) means UTF-16. Yes, that is f**ken annoying. FPC should have named it what it really is - UTF16String! But instead they followed Delphi like a lemming and named it UnicodeString. In reality, UNICODE means text with an encoding of any of UTF-8, UTF-16LE, UTF-16BE, or UTF-32. In terms of Delphi and FPC, they decided Unicode = UTF-16. I'm not even sure if they mean LE or BE. 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 From pascaldragon at googlemail.com Mon Aug 14 18:47:58 2017 From: pascaldragon at googlemail.com (Sven Barth) Date: Mon, 14 Aug 2017 18:47:58 +0200 Subject: [Lazarus] String vs WideString In-Reply-To: References: <20170812223247.73330e02@limapholos.matflo.wg> <20170812224956.4e624b23@limapholos.matflo.wg> <1ivuocdrq736eamemh6mp6h9old5omrssn@4ax.com> <38b0193a-eb86-4d6a-6292-f2203daff126@mccallumwhyman.com> <20170814154654.52d5d1d4@limapholos.matflo.wg> Message-ID: Am 14.08.2017 16:11 schrieb "Tony Whyman via Lazarus" < lazarus at lists.lazarus-ide.org>: > If nothing else, FPC Lazarus could do with a clean-up of both terminology and string types. Indeed, why isn't there a single container string type for all character sets where the encoding whether a legacy code page, UTF8, UTF16 or UTF32 is simply a dynamic attribute of the type - a sort of extended AnsiString? The main problem of such a dynamic type would be the inability to do fast indexing as the compiler would need to insert runtime checks for the size of a character. I had already thought the same, but then had to discard the idea due to this. Regards, Sven -------------- next part -------------- An HTML attachment was scrubbed... URL: From pascaldragon at googlemail.com Mon Aug 14 18:49:58 2017 From: pascaldragon at googlemail.com (Sven Barth) Date: Mon, 14 Aug 2017 18:49:58 +0200 Subject: [Lazarus] String vs WideString In-Reply-To: References: <20170812223247.73330e02@limapholos.matflo.wg> <20170812224956.4e624b23@limapholos.matflo.wg> <1ivuocdrq736eamemh6mp6h9old5omrssn@4ax.com> <38b0193a-eb86-4d6a-6292-f2203daff126@mccallumwhyman.com> <20170814154654.52d5d1d4@limapholos.matflo.wg> <70ad8658-8284-2c33-6604-3afe0eef5311@geldenhuys.co.uk> Message-ID: Am 14.08.2017 16:21 schrieb "Graeme Geldenhuys via Lazarus" < lazarus at lists.lazarus-ide.org>: > > On 2017-08-14 15:11, Tony Whyman via Lazarus wrote: >> >> ambiguous a term - especially as the Delphi/FPC UnicodeString type >> exists and probably (but I'm not certain) means UTF-16. > > > Yes, that is f**ken annoying. FPC should have named it what it really is - UTF16String! But instead they followed Delphi like a lemming and named it UnicodeString. Because the crowd demanding Delphi compatibility is larger than the crowd demanding exact terminology. > In reality, UNICODE means text with an encoding of any of UTF-8, UTF-16LE, UTF-16BE, or UTF-32. > > In terms of Delphi and FPC, they decided Unicode = UTF-16. I'm not even sure if they mean LE or BE. If I remember correctly it depends on the endianess of the platform... Though I could be wrong. Regards, Sven -------------- next part -------------- An HTML attachment was scrubbed... URL: From md at delfire.net Mon Aug 14 19:41:34 2017 From: md at delfire.net (Marcos Douglas B. Santos) Date: Mon, 14 Aug 2017 14:41:34 -0300 Subject: [Lazarus] String vs WideString In-Reply-To: References: <20170812223247.73330e02@limapholos.matflo.wg> <20170812224956.4e624b23@limapholos.matflo.wg> <1ivuocdrq736eamemh6mp6h9old5omrssn@4ax.com> <38b0193a-eb86-4d6a-6292-f2203daff126@mccallumwhyman.com> Message-ID: On Mon, Aug 14, 2017 at 10:21 AM, Tony Whyman via Lazarus wrote: > > On 14/08/17 14:11, Marcos Douglas B. Santos via Lazarus wrote: >> >> FPC and Lazarus claim they are cross-platform — this is a fact — and >> because that, IMHO, both should be use in only one way in every >> system, don't you think? >> >> Best regards, >> Marcos Douglas > > Precisely. But why this fixation on UTF-16/Unicode and not UTF8? I have no fixation in any Unicode flavors... My "problem" is because I use Windows, not Linux where UTF8 is the default. > Lazarus is already a UTF8 environment. > > Much of the LCL assumes UTF8. > > UTF8 is arguably a much more efficient way to store and transfer data > > UTF-16/Unicode can only store 65,536 characters while the Unicode standard > (that covers UTF8 as well) defines 136,755 characters. > > UTF-16/Unicode's main advantage seems to be for rapid indexing of large > strings. > > You made need UTF-16/Unicode support for accessing Microsoft APIs but apart > from that, why is it being promoted as the universal standard? I didn't propose that. But take a look in other languages, see what they are using. Best regards, Marcos Douglas From juha.manninen62 at gmail.com Mon Aug 14 23:01:55 2017 From: juha.manninen62 at gmail.com (Juha Manninen) Date: Tue, 15 Aug 2017 00:01:55 +0300 Subject: [Lazarus] String vs WideString In-Reply-To: References: <20170812223247.73330e02@limapholos.matflo.wg> <20170812224956.4e624b23@limapholos.matflo.wg> <1ivuocdrq736eamemh6mp6h9old5omrssn@4ax.com> <38b0193a-eb86-4d6a-6292-f2203daff126@mccallumwhyman.com> <20170814154654.52d5d1d4@limapholos.matflo.wg> Message-ID: On Mon, Aug 14, 2017 at 5:11 PM, Tony Whyman via Lazarus wrote: > Indeed, why isn't there a single container string type for > all character sets where the encoding whether a legacy code page, UTF8, > UTF16 or UTF32 is simply a dynamic attribute of the type - a sort of > extended AnsiString? As Sven Barth wrote, they have different size of char. Tony Whyman, this issue has been discussed again and again for the past 10+ years first in FPC mailing lists and then in Lazarus lists. The current Unicode support in Lazarus works f***ing well and is amazingly compatible with Delphi. WinAPI parameters may require an explicit temporary UnicodeString variable but even then the code is compatible with Delphi. Tony Whyman, Marcos Douglas and Michael Schnell, please study the facts. For starters, this is about the current Unicode support in Lazarus: http://wiki.freepascal.org/Unicode_Support_in_Lazarus I think the dynamic encoding and automatic conversion now work perfectly well. If you have a piece of code where it does not work, please ask for detailed info. Juha From mschnell at lumino.de Tue Aug 15 09:59:38 2017 From: mschnell at lumino.de (Michael Schnell) Date: Tue, 15 Aug 2017 09:59:38 +0200 Subject: [Lazarus] String vs WideString In-Reply-To: References: <20170812223247.73330e02@limapholos.matflo.wg> <20170812224956.4e624b23@limapholos.matflo.wg> <1ivuocdrq736eamemh6mp6h9old5omrssn@4ax.com> <38b0193a-eb86-4d6a-6292-f2203daff126@mccallumwhyman.com> <20170814154654.52d5d1d4@limapholos.matflo.wg> <70ad8658-8284-2c33-6604-3afe0eef5311@geldenhuys.co.uk> Message-ID: <789c3859-b281-8fa5-67ed-f8c46e55a76c@lumino.de> On 14.08.2017 18:49, Sven Barth via Lazarus wrote: > > Because the crowd demanding Delphi compatibility is larger than the > crowd demanding exact terminology. > ... or even a revised concept avoiding the junk presented by Embarcadero :( But obviously the fpc team has no choice. -Michael From mschnell at lumino.de Tue Aug 15 10:03:14 2017 From: mschnell at lumino.de (Michael Schnell) Date: Tue, 15 Aug 2017 10:03:14 +0200 Subject: [Lazarus] String vs WideString In-Reply-To: References: <20170812223247.73330e02@limapholos.matflo.wg> <20170812224956.4e624b23@limapholos.matflo.wg> <1ivuocdrq736eamemh6mp6h9old5omrssn@4ax.com> <38b0193a-eb86-4d6a-6292-f2203daff126@mccallumwhyman.com> <20170814154654.52d5d1d4@limapholos.matflo.wg> Message-ID: <107cdbed-d945-853e-16d3-b6e6fbad5de5@lumino.de> On 14.08.2017 18:47, Sven Barth via Lazarus wrote: > > The main problem of such a dynamic type would be the inability to do > fast indexing as the compiler would need to insert runtime checks for > the size of a character. > What "indexing" do you think of ? Could you give an example where such a difference is supposed to get important ? (As you know I wrote a paper where I claimed the contrary. I'd like to revise same if necessary.) -Michael From tony.whyman at mccallumwhyman.com Tue Aug 15 10:34:57 2017 From: tony.whyman at mccallumwhyman.com (Tony Whyman) Date: Tue, 15 Aug 2017 09:34:57 +0100 Subject: [Lazarus] String vs WideString In-Reply-To: References: <20170812223247.73330e02@limapholos.matflo.wg> <20170812224956.4e624b23@limapholos.matflo.wg> <1ivuocdrq736eamemh6mp6h9old5omrssn@4ax.com> <38b0193a-eb86-4d6a-6292-f2203daff126@mccallumwhyman.com> <20170814154654.52d5d1d4@limapholos.matflo.wg> Message-ID: On 14/08/17 17:47, Sven Barth via Lazarus wrote: > The main problem of such a dynamic type would be the inability to do > fast indexing as the compiler would need to insert runtime checks for > the size of a character. I had already thought the same, but then had > to discard the idea due to this. Is this really a big problem? It is not as if it would be necessary to do a table lookup everytime you index a string as the indexing method could be an attribute of the string and updated with the character encoding attribute. Is it really that complicated for the compiler to generate code that jumps to an indexing method depending upon a data attribute? Is your problem really more about the result type as, depending on the character width, the result could be an AnsiChar or WideChar or a UTF8 character for which I don't believe there is a defined char type (other than an arguable mis-use of UCS4Char)? I can accept that a clear up of this area would also have to extend to the char types as well - but I would also argue that that is well overdue. On a quick count, I found 7 different char types in the system unit. From nc-gaertnma at netcologne.de Tue Aug 15 11:10:45 2017 From: nc-gaertnma at netcologne.de (Mattias Gaertner) Date: Tue, 15 Aug 2017 11:10:45 +0200 Subject: [Lazarus] String vs WideString In-Reply-To: References: <20170812223247.73330e02@limapholos.matflo.wg> <20170812224956.4e624b23@limapholos.matflo.wg> Message-ID: <20170815111045.315dfcb3@limapholos.matflo.wg> On Sat, 12 Aug 2017 17:56:58 -0300 "Marcos Douglas B. Santos via Lazarus" wrote: >[...] > > Which one? Do you mean Windows CP-1252? > > Yes... > But would it make any difference? Just > >>[...] > >> Warning: Implicit string type conversion from "AnsiString" to "WideString" > > > > Explicit type cast: > > > > Lib.SetLicense( > > WideString(IniFile.ReadString('TheLib', 'license', '')) > > ); > > Wow... everywhere? :( You could instead define an overloaded Lib.SetLicense(AnsiString). Or you could disable this hint altogether for your project (not recommended). Select the message in the Messages window. Right click and click on add -vm.... Mattias From nc-gaertnma at netcologne.de Tue Aug 15 11:13:13 2017 From: nc-gaertnma at netcologne.de (Mattias Gaertner) Date: Tue, 15 Aug 2017 11:13:13 +0200 Subject: [Lazarus] String vs WideString In-Reply-To: References: <20170812223247.73330e02@limapholos.matflo.wg> <20170812224956.4e624b23@limapholos.matflo.wg> <1ivuocdrq736eamemh6mp6h9old5omrssn@4ax.com> <38b0193a-eb86-4d6a-6292-f2203daff126@mccallumwhyman.com> <20170814154654.52d5d1d4@limapholos.matflo.wg> Message-ID: <20170815111313.0d368eaf@limapholos.matflo.wg> On Mon, 14 Aug 2017 18:47:58 +0200 Sven Barth via Lazarus wrote: >[...] > The main problem of such a dynamic type would be the inability to do fast > indexing as the compiler would need to insert runtime checks for the size > of a character. I had already thought the same, but then had to discard the > idea due to this. IMHO the main problem of adding a new string type is https://xkcd.com/927/ Mattias From tony.whyman at mccallumwhyman.com Tue Aug 15 11:15:36 2017 From: tony.whyman at mccallumwhyman.com (Tony Whyman) Date: Tue, 15 Aug 2017 10:15:36 +0100 Subject: [Lazarus] String vs WideString In-Reply-To: References: <20170812223247.73330e02@limapholos.matflo.wg> <20170812224956.4e624b23@limapholos.matflo.wg> <1ivuocdrq736eamemh6mp6h9old5omrssn@4ax.com> <38b0193a-eb86-4d6a-6292-f2203daff126@mccallumwhyman.com> <20170814154654.52d5d1d4@limapholos.matflo.wg> Message-ID: On 14/08/17 22:01, Juha Manninen via Lazarus wrote: > Tony Whyman, this issue has been discussed again and again for the > past 10+ years first in FPC mailing lists and then in Lazarus lists. > The current Unicode support in Lazarus works f***ing well and is > amazingly compatible with Delphi. > WinAPI parameters may require an explicit temporary UnicodeString > variable but even then the code is compatible with Delphi. > > Tony Whyman, Marcos Douglas and Michael Schnell, please study the facts. > For starters, this is about the current Unicode support in Lazarus: > http://wiki.freepascal.org/Unicode_Support_in_Lazarus > I think the dynamic encoding and automatic conversion now work perfectly well. > If you have a piece of code where it does not work, please ask for > detailed info. If a topic keeps on being discussed after 10+ years of argument, the reason is usually either (a) the problem and its solution have not been documented properly, or (b) the outcome is an unsatisfactory compromise. In this case, I would argue that both are true. I went back and read the wiki article you mentioned and was no more the wiser as to why the current mess exists. Is it really no more than because Delphi continues to screw up in this area, so must FPC? The body of the article appears to be a set of notes - not necessarily wrong in themselves but lacking the background and context needed to explain why it is like it is. This problem will keep coming up until it is fixed properly and, by that, I mean the that solution is consistent, understandable intuitively and well documented. Windows eccentricity also need to kept to Windows. Here is my wish list: 1. Stop using the term "Unicode". It is too ambiguous. It is used as both an all embracing term for multi-byte encoding and as a synonym for UTF16 and that is really too confusing. The problem is made worse by having UnicodeString as a two byte wide string type in both FPC and Delphi. 2. Clean up the char type. When Wirth created the "char" type in Pascal it was a simple ASCII or EBCDIC character. There are now seven different char types (including type equivalence) with no guidelines on when each is applicable. This is too many. Why shouldn't there be a single char type that intuitively represents a single character regardless of how many bytes are used to represent it. Yes, in a world where we have to live with UTF8, UTF16, UTF32, legacy code pages and Chinese variations on UTF8, that means that dynamic attributes have to be included in the type. But isn't that the only way to have consistent and intuitive character handling? 3. The problem with string handling today is that it is not based on a consistent approach to the character type. If you clean up character handling then the model for string handling should become obvious. A string is after all no more than a container for a character array and which should be constrained to have the same character encoding. A string should intuitively represent a string of text regardless of how many bytes are used to represent each character and with dynamic attributes to tell you how it is encoded. 4. FPC should clean up Delphi's mess for it. If a unified string type follows a consistent model then it should be possible to make all Delphi string types synonyms. You will need to allow exceptions for legacy programs that insist on manipulating the bytes themselves - but that is not rocket science. There is also the issue of the Windows API and its insistence on Wide Strings - but isn't that why calling conventions such as cdecl and stdcall exist - to tell the compiler when it needs to reformat the call for a given API convention. Tony Whyman -------------- next part -------------- An HTML attachment was scrubbed... URL: From tony.whyman at mccallumwhyman.com Tue Aug 15 11:17:22 2017 From: tony.whyman at mccallumwhyman.com (Tony Whyman) Date: Tue, 15 Aug 2017 10:17:22 +0100 Subject: [Lazarus] String vs WideString In-Reply-To: <20170815111313.0d368eaf@limapholos.matflo.wg> References: <20170812223247.73330e02@limapholos.matflo.wg> <20170812224956.4e624b23@limapholos.matflo.wg> <1ivuocdrq736eamemh6mp6h9old5omrssn@4ax.com> <38b0193a-eb86-4d6a-6292-f2203daff126@mccallumwhyman.com> <20170814154654.52d5d1d4@limapholos.matflo.wg> <20170815111313.0d368eaf@limapholos.matflo.wg> Message-ID: <3f4ddc9d-92cf-3e7e-9197-264f55190b0e@mccallumwhyman.com> You can me as a "like" on that one. On 15/08/17 10:13, Mattias Gaertner via Lazarus wrote: > IMHO the main problem of adding a new string type is > https://xkcd.com/927/ From michael at freepascal.org Tue Aug 15 11:25:26 2017 From: michael at freepascal.org (Michael Van Canneyt) Date: Tue, 15 Aug 2017 11:25:26 +0200 (CEST) Subject: [Lazarus] String vs WideString In-Reply-To: <20170815111313.0d368eaf@limapholos.matflo.wg> References: <20170812223247.73330e02@limapholos.matflo.wg> <20170812224956.4e624b23@limapholos.matflo.wg> <1ivuocdrq736eamemh6mp6h9old5omrssn@4ax.com> <38b0193a-eb86-4d6a-6292-f2203daff126@mccallumwhyman.com> <20170814154654.52d5d1d4@limapholos.matflo.wg> <20170815111313.0d368eaf@limapholos.matflo.wg> Message-ID: On Tue, 15 Aug 2017, Mattias Gaertner via Lazarus wrote: > On Mon, 14 Aug 2017 18:47:58 +0200 > Sven Barth via Lazarus wrote: > >> [...] >> The main problem of such a dynamic type would be the inability to do fast >> indexing as the compiler would need to insert runtime checks for the size >> of a character. I had already thought the same, but then had to discard the >> idea due to this. > > IMHO the main problem of adding a new string type is > https://xkcd.com/927/ Exactly. I don't think we should add even more. As it is now, FPC offers a way out for all cases: WideString/UnicodeString for those that want 2-byte characters. A codepage-aware single-byte string for those that want 1-byte characters. The shortstring is even still available. Attempting to store binary data in a string is not advisable. Dynamic arrays, TBytes and - in the worst case - TBytesStream are powerful enough to cover most use-cases in this area. Michael. From mschnell at lumino.de Tue Aug 15 11:49:24 2017 From: mschnell at lumino.de (Michael Schnell) Date: Tue, 15 Aug 2017 11:49:24 +0200 Subject: [Lazarus] String vs WideString In-Reply-To: References: <20170812223247.73330e02@limapholos.matflo.wg> <20170812224956.4e624b23@limapholos.matflo.wg> <1ivuocdrq736eamemh6mp6h9old5omrssn@4ax.com> <38b0193a-eb86-4d6a-6292-f2203daff126@mccallumwhyman.com> <20170814154654.52d5d1d4@limapholos.matflo.wg> <20170815111313.0d368eaf@limapholos.matflo.wg> Message-ID: <49d88133-d578-d80c-c080-58b635602054@lumino.de> On 15.08.2017 11:25, Michael Van Canneyt via Lazarus wrote: > WideString/UnicodeString for those that want 2-byte characters. > A codepage-aware single-byte string for those that want 1-byte > characters. > The shortstring is even still available. IM (often stated) O, this does not help as long as TStrings does not without forced auto-conversion support the string type the user is inclined to choose. This obviously requires an (additional) fully dynamic string brand. This (again obviously) is not the "Embarcadero way", but supposedly does not necessarily lead to incompatibility regarding the user code. -Michael From michael at freepascal.org Tue Aug 15 11:52:49 2017 From: michael at freepascal.org (Michael Van Canneyt) Date: Tue, 15 Aug 2017 11:52:49 +0200 (CEST) Subject: [Lazarus] String vs WideString In-Reply-To: <49d88133-d578-d80c-c080-58b635602054@lumino.de> References: <20170812223247.73330e02@limapholos.matflo.wg> <20170812224956.4e624b23@limapholos.matflo.wg> <1ivuocdrq736eamemh6mp6h9old5omrssn@4ax.com> <38b0193a-eb86-4d6a-6292-f2203daff126@mccallumwhyman.com> <20170814154654.52d5d1d4@limapholos.matflo.wg> <20170815111313.0d368eaf@limapholos.matflo.wg> <49d88133-d578-d80c-c080-58b635602054@lumino.de> Message-ID: On Tue, 15 Aug 2017, Michael Schnell via Lazarus wrote: > On 15.08.2017 11:25, Michael Van Canneyt via Lazarus wrote: >> WideString/UnicodeString for those that want 2-byte characters. >> A codepage-aware single-byte string for those that want 1-byte >> characters. >> The shortstring is even still available. > > IM (often stated) O, this does not help as long as TStrings does not > without forced auto-conversion support the string type the user is > inclined to choose. Please check TStrings in trunk. This exists. procedure LoadFromFile(const FileName: string; AEncoding: TEncoding); overload; virtual; procedure LoadFromStream(Stream: TStream; AEncoding: TEncoding); overload; virtual; The only 'problem' is that TStrings uses a single-byte string. This cannot be solved properly except by duplicating the classes unit. Michael. From mschnell at lumino.de Tue Aug 15 11:57:09 2017 From: mschnell at lumino.de (Michael Schnell) Date: Tue, 15 Aug 2017 11:57:09 +0200 Subject: [Lazarus] String vs WideString In-Reply-To: References: <20170812223247.73330e02@limapholos.matflo.wg> <20170812224956.4e624b23@limapholos.matflo.wg> <1ivuocdrq736eamemh6mp6h9old5omrssn@4ax.com> <38b0193a-eb86-4d6a-6292-f2203daff126@mccallumwhyman.com> <20170814154654.52d5d1d4@limapholos.matflo.wg> Message-ID: <5b2fac30-ba35-5be7-fc77-ab6443e003b2@lumino.de> On 15.08.2017 11:15, Tony Whyman via Lazarus wrote: > > In this case, I would argue that both are true. And the culprit obviously is Embarcadeo and not the fpc or the Lazarus team, who did their best to try to do a compatible and implementation that is really workable on the multiple supported platforms (which E$ did not feel necessary when they released the encoding aware strings). Maybe a better solution can be found, but who would want to nudge the fpc / Lazarus developers to invest a huge amount of time to create it and then make sure it is decently tested stable ? -Michael From mschnell at lumino.de Tue Aug 15 12:02:28 2017 From: mschnell at lumino.de (Michael Schnell) Date: Tue, 15 Aug 2017 12:02:28 +0200 Subject: [Lazarus] String vs WideString In-Reply-To: References: <20170812223247.73330e02@limapholos.matflo.wg> <20170812224956.4e624b23@limapholos.matflo.wg> <1ivuocdrq736eamemh6mp6h9old5omrssn@4ax.com> <38b0193a-eb86-4d6a-6292-f2203daff126@mccallumwhyman.com> <20170814154654.52d5d1d4@limapholos.matflo.wg> <20170815111313.0d368eaf@limapholos.matflo.wg> <49d88133-d578-d80c-c080-58b635602054@lumino.de> Message-ID: On 15.08.2017 11:52, Michael Van Canneyt via Lazarus wrote: > This cannot be solved properly except by duplicating the classes unit. Sorry to disagree, but IMHO this can only be solved properly by defining an additional fully dynamically encoded string type and use same for TStrings (see -> http://wiki.freepascal.org/not_Delphi_compatible_enhancement_for_Unicode_Support ) But I am perfectly aware that implementing this would be a huge effort (see other mail here), and nobody i entitled to ask for this. (I wrote the article just to elaborate what was discussed in the fpc mailing list at that time.) -Michael From nc-gaertnma at netcologne.de Tue Aug 15 12:11:37 2017 From: nc-gaertnma at netcologne.de (Mattias Gaertner) Date: Tue, 15 Aug 2017 12:11:37 +0200 Subject: [Lazarus] String vs WideString In-Reply-To: References: <20170812224956.4e624b23@limapholos.matflo.wg> <1ivuocdrq736eamemh6mp6h9old5omrssn@4ax.com> <38b0193a-eb86-4d6a-6292-f2203daff126@mccallumwhyman.com> <20170814154654.52d5d1d4@limapholos.matflo.wg> <20170815111313.0d368eaf@limapholos.matflo.wg> <49d88133-d578-d80c-c080-58b635602054@lumino.de> Message-ID: <20170815121137.2729f7a1@limapholos.matflo.wg> On Tue, 15 Aug 2017 12:02:28 +0200 Michael Schnell via Lazarus wrote: > On 15.08.2017 11:52, Michael Van Canneyt via Lazarus wrote: > > This cannot be solved properly except by duplicating the classes unit. > > Sorry to disagree, but IMHO this can only be solved properly by defining > an additional fully dynamically encoded string type and use same for > TStrings (see -> > http://wiki.freepascal.org/not_Delphi_compatible_enhancement_for_Unicode_Support > ) It does not explain what the characters of DynamicString are, does it? Mattias From michael at freepascal.org Tue Aug 15 12:15:55 2017 From: michael at freepascal.org (Michael Van Canneyt) Date: Tue, 15 Aug 2017 12:15:55 +0200 (CEST) Subject: [Lazarus] String vs WideString In-Reply-To: <20170815121137.2729f7a1@limapholos.matflo.wg> References: <20170812224956.4e624b23@limapholos.matflo.wg> <1ivuocdrq736eamemh6mp6h9old5omrssn@4ax.com> <38b0193a-eb86-4d6a-6292-f2203daff126@mccallumwhyman.com> <20170814154654.52d5d1d4@limapholos.matflo.wg> <20170815111313.0d368eaf@limapholos.matflo.wg> <49d88133-d578-d80c-c080-58b635602054@lumino.de> <20170815121137.2729f7a1@limapholos.matflo.wg> Message-ID: On Tue, 15 Aug 2017, Mattias Gaertner via Lazarus wrote: > On Tue, 15 Aug 2017 12:02:28 +0200 > Michael Schnell via Lazarus wrote: > >> On 15.08.2017 11:52, Michael Van Canneyt via Lazarus wrote: >> > This cannot be solved properly except by duplicating the classes unit. >> >> Sorry to disagree, but IMHO this can only be solved properly by defining >> an additional fully dynamically encoded string type and use same for >> TStrings (see -> >> http://wiki.freepascal.org/not_Delphi_compatible_enhancement_for_Unicode_Support >> ) > > It does not explain what the characters of DynamicString are, does it? I was just going to write that. The problem of the element size is circumvented by simply not digging into it. What does S[2] mean in your proposal ? Is it 1, 2, 4 or even 8 bytes ? Michael. From mschnell at lumino.de Tue Aug 15 12:34:45 2017 From: mschnell at lumino.de (Michael Schnell) Date: Tue, 15 Aug 2017 12:34:45 +0200 Subject: [Lazarus] String vs WideString In-Reply-To: <20170815121137.2729f7a1@limapholos.matflo.wg> References: <20170812224956.4e624b23@limapholos.matflo.wg> <1ivuocdrq736eamemh6mp6h9old5omrssn@4ax.com> <38b0193a-eb86-4d6a-6292-f2203daff126@mccallumwhyman.com> <20170814154654.52d5d1d4@limapholos.matflo.wg> <20170815111313.0d368eaf@limapholos.matflo.wg> <49d88133-d578-d80c-c080-58b635602054@lumino.de> <20170815121137.2729f7a1@limapholos.matflo.wg> Message-ID: <8e5c1c2f-caf2-7237-e9e9-022a188c3996@lumino.de> On 15.08.2017 12:11, Mattias Gaertner via Lazarus wrote: > It does not explain what the characters of DynamicString are, does it? I don't understand what you are asking. The element size and encoding of a Dynamic String ("CP_ANY" in the document) are not predefined, but depend on the content: http://wiki.freepascal.org/not_Delphi_compatible_enhancement_for_Unicode_Support -> Defining String variables and String types: > *CP_ANY* = $FF00 // ElementSize dynamically assigned // fully > dynamical String for intermediate storing string content // just > assigned to the Type or variable, never used in the "Encoding" field > in the string header. Hence it stores the "branding" when it is assigned to from a string with a fixed branding (such as *CP_UTF8*), and the content is auto-converted if necessary when assigning form CP_ANY to a fixed branded string variable. If (in your example) the data is read from a file, a CP_ANY Strings based StringList would keep the encoding/char_size of the data as t is in the file (it would need to somehow get to know the presumed encoding of the file, anyway) and store that information in the EncodingBrandNumber and ElementSize fields (which do exist in any "NewString" variable, anyway), in each String read. If the user assignes an element of the stringlist to a fixed branding (such as *CP_UTF8*), the content obviously is auto-converted if necessary when assigning form CP_ANY to a fixed branded string variable, as usual. In fact I suppose that the current implementation of TStringlist does not use new strings to store the data on the heap, but I never said that trying to implement such idea would not require a lot of work. -Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: From mschnell at lumino.de Tue Aug 15 12:44:10 2017 From: mschnell at lumino.de (Michael Schnell) Date: Tue, 15 Aug 2017 12:44:10 +0200 Subject: [Lazarus] String vs WideString In-Reply-To: References: <1ivuocdrq736eamemh6mp6h9old5omrssn@4ax.com> <38b0193a-eb86-4d6a-6292-f2203daff126@mccallumwhyman.com> <20170814154654.52d5d1d4@limapholos.matflo.wg> <20170815111313.0d368eaf@limapholos.matflo.wg> <49d88133-d578-d80c-c080-58b635602054@lumino.de> <20170815121137.2729f7a1@limapholos.matflo.wg> Message-ID: <27d964ce-1731-4be6-476d-c196d6646850@lumino.de> On 15.08.2017 12:15, Michael Van Canneyt via Lazarus wrote: > What does S[2] mean in your proposal ? Is it 1, 2, 4 or even 8 bytes ? Regarding the users' appreciation, the S[x] notation is decently incompatible between the different string types and compiler versions. There were hundreds of complains in all the appropriate forums and mailing list. So not much additional harm can be done, anyway. I suggest that it should be according to the character_size definition stored S, and the operation c := S[x] should transfer the appropriate count of bits, provided the type of c allows for taking them. This seems to be compatible to the current implementation of any 1-Byte brand and UTF16. -Michael From michael at freepascal.org Tue Aug 15 12:51:49 2017 From: michael at freepascal.org (Michael Van Canneyt) Date: Tue, 15 Aug 2017 12:51:49 +0200 (CEST) Subject: [Lazarus] String vs WideString In-Reply-To: <27d964ce-1731-4be6-476d-c196d6646850@lumino.de> References: <1ivuocdrq736eamemh6mp6h9old5omrssn@4ax.com> <38b0193a-eb86-4d6a-6292-f2203daff126@mccallumwhyman.com> <20170814154654.52d5d1d4@limapholos.matflo.wg> <20170815111313.0d368eaf@limapholos.matflo.wg> <49d88133-d578-d80c-c080-58b635602054@lumino.de> <20170815121137.2729f7a1@limapholos.matflo.wg> <27d964ce-1731-4be6-476d-c196d6646850@lumino.de> Message-ID: On Tue, 15 Aug 2017, Michael Schnell via Lazarus wrote: > On 15.08.2017 12:15, Michael Van Canneyt via Lazarus wrote: >> What does S[2] mean in your proposal ? Is it 1, 2, 4 or even 8 bytes ? > Regarding the users' appreciation, the S[x] notation is decently > incompatible between the different string types and compiler versions. Of course not. It's 1 byte for ansistring, 2 bytes for widestring. The point is that the compiler knows how many bytes it is based on the declaration of S. In your proposal, it is dynamic, if I understand it correctly. > There were hundreds of complains in all the appropriate forums and > mailing list. Complaints about what exactly ? > > So not much additional harm can be done, anyway. > > I suggest that it should be according to the character_size definition > stored S, and the operation c := S[x] should transfer the appropriate > count of bits, provided the type of c allows for taking them. As far as I understand your proposal, this currently cannot be done ? The compiler needs to know the S[X] size at compile time. Michael. From mailinglists at geldenhuys.co.uk Tue Aug 15 13:19:57 2017 From: mailinglists at geldenhuys.co.uk (Graeme Geldenhuys) Date: Tue, 15 Aug 2017 12:19:57 +0100 Subject: [Lazarus] The new kid is growing up fast Message-ID: <9f46c1f8-c4b1-846b-601b-e86e898bdac2@geldenhuys.co.uk> Hi guys, Just wanted to show you guys something. The new kid on the block is growing up very fast.... CrossVCL. https://www.youtube.com/watch?v=_lr_BQlXvkk I believe the programmer is the ex-FMX (FireMonkey) developer that was let go by Embarcadero, and he is hitting back with a vengeance. The CrossVCL project has grown from nothing to something in an extremely short time. Coming from a toolkit designer myself, that is very impressive to see. 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 From mschnell at lumino.de Tue Aug 15 13:35:22 2017 From: mschnell at lumino.de (Michael Schnell) Date: Tue, 15 Aug 2017 13:35:22 +0200 Subject: [Lazarus] The new kid is growing up fast In-Reply-To: <9f46c1f8-c4b1-846b-601b-e86e898bdac2@geldenhuys.co.uk> References: <9f46c1f8-c4b1-846b-601b-e86e898bdac2@geldenhuys.co.uk> Message-ID: <6b24c127-5799-04bf-3537-2b919c37bfb5@lumino.de> On 15.08.2017 13:19, Graeme Geldenhuys via Lazarus wrote: > Just wanted to show you guys something. Great. CrossVCL seems to allow to easily port Delphi VCL applications to Mac and Linux. How to compare it against Lazarus ? -Michael From bartjunk64 at gmail.com Tue Aug 15 14:02:16 2017 From: bartjunk64 at gmail.com (Bart) Date: Tue, 15 Aug 2017 14:02:16 +0200 Subject: [Lazarus] String vs WideString In-Reply-To: References: <20170812223247.73330e02@limapholos.matflo.wg> <20170812224956.4e624b23@limapholos.matflo.wg> <1ivuocdrq736eamemh6mp6h9old5omrssn@4ax.com> <38b0193a-eb86-4d6a-6292-f2203daff126@mccallumwhyman.com> <20170814154654.52d5d1d4@limapholos.matflo.wg> Message-ID: On 8/15/17, Tony Whyman via Lazarus wrote: > 2. Clean up the char type. > > Why shouldn't there be a single char > type that intuitively represents a single character regardless of > how many bytes are used to represent it. You would have to define what "a single character" means in the first place. This is especially important when it involves precomposed characters and combining characters. Bart From mschnell at lumino.de Tue Aug 15 14:26:34 2017 From: mschnell at lumino.de (Michael Schnell) Date: Tue, 15 Aug 2017 14:26:34 +0200 Subject: [Lazarus] String vs WideString In-Reply-To: References: <20170812223247.73330e02@limapholos.matflo.wg> <20170812224956.4e624b23@limapholos.matflo.wg> <1ivuocdrq736eamemh6mp6h9old5omrssn@4ax.com> <38b0193a-eb86-4d6a-6292-f2203daff126@mccallumwhyman.com> <20170814154654.52d5d1d4@limapholos.matflo.wg> Message-ID: On 15.08.2017 11:15, Tony Whyman via Lazarus wrote: > Why shouldn't there be a single char type that intuitively represents > a single character regardless of how many bytes are used to represent it. I suppose by "char" you mean "single printable thingy" with Unicode it's rather debatable what such a thingy is. Hence a Unicode singe char would need to be just be a Unicode string. -Michael From mschnell at lumino.de Tue Aug 15 14:30:40 2017 From: mschnell at lumino.de (Michael Schnell) Date: Tue, 15 Aug 2017 14:30:40 +0200 Subject: [Lazarus] String vs WideString In-Reply-To: References: <20170812223247.73330e02@limapholos.matflo.wg> <20170812224956.4e624b23@limapholos.matflo.wg> <1ivuocdrq736eamemh6mp6h9old5omrssn@4ax.com> <38b0193a-eb86-4d6a-6292-f2203daff126@mccallumwhyman.com> <20170814154654.52d5d1d4@limapholos.matflo.wg> Message-ID: <44d3fc5c-8833-0dec-7b49-266bd6eea020@lumino.de> On 15.08.2017 11:15, Tony Whyman via Lazarus wrote: > > 3. The problem with string handling today is that it is not based on a > consistent approach to the character type. > > If you clean up character handling then the model for string > handling should become obvious. A string is after all no more than > a container for a character array and which should be constrained > to have the same character encoding. A string should intuitively > represent a string of text regardless of how many bytes are used > to represent each character and with dynamic attributes to tell > you how it is encoded. > > > 4. FPC should clean up Delphi's mess for it. If a unified string type > follows a consistent model then it should be possible to make all > Delphi string types synonyms. > > You will need to allow exceptions for legacy programs that insist > on manipulating the bytes themselves - but that is not rocket > science. There is also the issue of the Windows API and its > insistence on Wide Strings - but isn't that why calling > conventions such as cdecl and stdcall exist - to tell the compiler > when it needs to reformat the call for a given API convention. > > see -> http://wiki.freepascal.org/not_Delphi_compatible_enhancement_for_Unicode_Support -Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: From nc-gaertnma at netcologne.de Tue Aug 15 14:53:00 2017 From: nc-gaertnma at netcologne.de (Mattias Gaertner) Date: Tue, 15 Aug 2017 14:53:00 +0200 Subject: [Lazarus] String vs WideString In-Reply-To: References: <20170812223247.73330e02@limapholos.matflo.wg> <20170812224956.4e624b23@limapholos.matflo.wg> <1ivuocdrq736eamemh6mp6h9old5omrssn@4ax.com> <38b0193a-eb86-4d6a-6292-f2203daff126@mccallumwhyman.com> <20170814154654.52d5d1d4@limapholos.matflo.wg> Message-ID: <20170815145300.3deb1062@limapholos.matflo.wg> On Tue, 15 Aug 2017 14:26:34 +0200 Michael Schnell via Lazarus wrote: > On 15.08.2017 11:15, Tony Whyman via Lazarus wrote: > > Why shouldn't there be a single char type that intuitively represents > > a single character regardless of how many bytes are used to represent it. > > I suppose by "char" you mean "single printable thingy" with Unicode it's > rather debatable what such a thingy is. > > Hence a Unicode singe char would need to be just be a Unicode string. Do you mean a 'char' is a string in your proposal? Mattias From michael at freepascal.org Tue Aug 15 14:53:38 2017 From: michael at freepascal.org (Michael Van Canneyt) Date: Tue, 15 Aug 2017 14:53:38 +0200 (CEST) Subject: [Lazarus] String vs WideString In-Reply-To: <20170815145300.3deb1062@limapholos.matflo.wg> References: <20170812223247.73330e02@limapholos.matflo.wg> <20170812224956.4e624b23@limapholos.matflo.wg> <1ivuocdrq736eamemh6mp6h9old5omrssn@4ax.com> <38b0193a-eb86-4d6a-6292-f2203daff126@mccallumwhyman.com> <20170814154654.52d5d1d4@limapholos.matflo.wg> <20170815145300.3deb1062@limapholos.matflo.wg> Message-ID: On Tue, 15 Aug 2017, Mattias Gaertner via Lazarus wrote: > On Tue, 15 Aug 2017 14:26:34 +0200 > Michael Schnell via Lazarus wrote: > >> On 15.08.2017 11:15, Tony Whyman via Lazarus wrote: >> > Why shouldn't there be a single char type that intuitively represents >> > a single character regardless of how many bytes are used to represent it. >> >> I suppose by "char" you mean "single printable thingy" with Unicode it's >> rather debatable what such a thingy is. >> >> Hence a Unicode singe char would need to be just be a Unicode string. > > Do you mean a 'char' is a string in your proposal? That would be a neat recursive definition :) Michael. From mschnell at lumino.de Tue Aug 15 16:44:30 2017 From: mschnell at lumino.de (Michael Schnell) Date: Tue, 15 Aug 2017 16:44:30 +0200 Subject: [Lazarus] String vs WideString In-Reply-To: <20170815145300.3deb1062@limapholos.matflo.wg> References: <20170812223247.73330e02@limapholos.matflo.wg> <20170812224956.4e624b23@limapholos.matflo.wg> <1ivuocdrq736eamemh6mp6h9old5omrssn@4ax.com> <38b0193a-eb86-4d6a-6292-f2203daff126@mccallumwhyman.com> <20170814154654.52d5d1d4@limapholos.matflo.wg> <20170815145300.3deb1062@limapholos.matflo.wg> Message-ID: <7e106689-cd91-8fda-1dc6-f0273e5cd07d@lumino.de> On 15.08.2017 14:53, Mattias Gaertner via Lazarus wrote: > Do you mean a 'char' is a string in your proposal? Nope. In my proposal there would be Chars for any statically encoded String Type, hence 1, 2, 4, and 8 byte wide. (As regarding statically encoded string (and char) brands, it's just an extension of the existing paradigm. I did not think about the necessity to also have a dynamically encoded Char type. If yes, it (like a string) would need the additional fields for encoding number and bytes_per_char, and the appropriate compiler magic to handle them appropriately (workalike to a on-element string). -Michael From nc-gaertnma at netcologne.de Tue Aug 15 18:33:25 2017 From: nc-gaertnma at netcologne.de (Mattias Gaertner) Date: Tue, 15 Aug 2017 18:33:25 +0200 Subject: [Lazarus] String vs WideString In-Reply-To: <7e106689-cd91-8fda-1dc6-f0273e5cd07d@lumino.de> References: <20170812224956.4e624b23@limapholos.matflo.wg> <1ivuocdrq736eamemh6mp6h9old5omrssn@4ax.com> <38b0193a-eb86-4d6a-6292-f2203daff126@mccallumwhyman.com> <20170814154654.52d5d1d4@limapholos.matflo.wg> <20170815145300.3deb1062@limapholos.matflo.wg> <7e106689-cd91-8fda-1dc6-f0273e5cd07d@lumino.de> Message-ID: <20170815183325.10ea1a0f@limapholos.matflo.wg> On Tue, 15 Aug 2017 16:44:30 +0200 Michael Schnell via Lazarus wrote: > On 15.08.2017 14:53, Mattias Gaertner via Lazarus wrote: > > Do you mean a 'char' is a string in your proposal? > Nope. In my proposal there would be Chars for any statically encoded > String Type, hence 1, 2, 4, and 8 byte wide. (As regarding statically > encoded string (and char) brands, it's just an extension of the existing > paradigm. 8 bytes? Do you propose a string without the array operator [] ? Mattias From mailinglists at geldenhuys.co.uk Tue Aug 15 19:18:01 2017 From: mailinglists at geldenhuys.co.uk (Graeme Geldenhuys) Date: Tue, 15 Aug 2017 18:18:01 +0100 Subject: [Lazarus] String vs WideString In-Reply-To: References: <20170812223247.73330e02@limapholos.matflo.wg> <20170812224956.4e624b23@limapholos.matflo.wg> <1ivuocdrq736eamemh6mp6h9old5omrssn@4ax.com> <38b0193a-eb86-4d6a-6292-f2203daff126@mccallumwhyman.com> <20170814154654.52d5d1d4@limapholos.matflo.wg> <20170815111313.0d368eaf@limapholos.matflo.wg> <49d88133-d578-d80c-c080-58b635602054@lumino.de> Message-ID: On 2017-08-15 10:52, Michael Van Canneyt via Lazarus wrote: > The only 'problem' is that TStrings uses a single-byte string. Why can't that be changed to a UnicodeString or UTF8String - after all, the Unicode standard is meant to support all languages. I would have thought that would be an obvious move for a Unicode-aware RTL. TStrings could also be extended (if it hasn't already) to keep track of what encoding is read in from file, and what encoding in should procedure when lines are extracted - in case those two encodings are not the same. 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 From luca at wetron.es Tue Aug 15 19:29:23 2017 From: luca at wetron.es (Luca Olivetti) Date: Tue, 15 Aug 2017 19:29:23 +0200 Subject: [Lazarus] String vs WideString In-Reply-To: References: <20170812223247.73330e02@limapholos.matflo.wg> <20170812224956.4e624b23@limapholos.matflo.wg> <1ivuocdrq736eamemh6mp6h9old5omrssn@4ax.com> <38b0193a-eb86-4d6a-6292-f2203daff126@mccallumwhyman.com> <20170814154654.52d5d1d4@limapholos.matflo.wg> <20170815111313.0d368eaf@limapholos.matflo.wg> Message-ID: El 15/08/17 a les 11:25, Michael Van Canneyt via Lazarus ha escrit: > > Attempting to store binary data in a string is not advisable. Dynamic > arrays, TBytes and - in the worst case - TBytesStream are powerful > enough to > cover most use-cases in this area. I has worked extremely well and reliably until fpc 2.6.4 (i.e. with string=ansistring). Does it not work in 3.x? If not it's a big problem, not only for my code (that I can, reluctantly, change) but for 3rd party libraries/components (e.g. synapse comes to mind) Bye -- Luca Olivetti Wetron Automation Technology http://www.wetron.es/ Tel. +34 93 5883004 (Ext.3010) Fax +34 93 5883007 From wkitty42 at windstream.net Tue Aug 15 19:53:21 2017 From: wkitty42 at windstream.net (wkitty42 at windstream.net) Date: Tue, 15 Aug 2017 13:53:21 -0400 Subject: [Lazarus] String vs WideString In-Reply-To: References: <20170812223247.73330e02@limapholos.matflo.wg> <20170812224956.4e624b23@limapholos.matflo.wg> <1ivuocdrq736eamemh6mp6h9old5omrssn@4ax.com> <38b0193a-eb86-4d6a-6292-f2203daff126@mccallumwhyman.com> <20170814154654.52d5d1d4@limapholos.matflo.wg> <20170815111313.0d368eaf@limapholos.matflo.wg> Message-ID: <01f722fe-3e5d-eb63-e7cf-3f2c369e7529@windstream.net> On 08/15/2017 05:25 AM, Michael Van Canneyt via Lazarus wrote: > As it is now, FPC offers a way out for all cases: > > WideString/UnicodeString for those that want 2-byte characters. what if 3 and 4 byte characters are required? will they also work in UnicodeStrings? i'm looking at this from a linux POV but have been trying to come from the very old school DOS TP stuff using codepages... especially needing to be able to read codepage strings and properly convert all their characters to UTF-8... converting back would be a huge help, too... even with the possible loss of characters requiring replacing them with "?" or something to hold their place and show they didn't convert... that or even leaving them in their 2, 3 or 4 byte form and let those using older codepage stuff see them raw... -- NOTE: No off-list assistance is given without prior approval. *Please keep mailing list traffic on the list unless* *a signed and pre-paid contract is in effect with us.* From mailinglists at geldenhuys.co.uk Tue Aug 15 21:14:10 2017 From: mailinglists at geldenhuys.co.uk (Graeme Geldenhuys) Date: Tue, 15 Aug 2017 20:14:10 +0100 Subject: [Lazarus] String vs WideString In-Reply-To: References: <20170812223247.73330e02@limapholos.matflo.wg> <20170812224956.4e624b23@limapholos.matflo.wg> <1ivuocdrq736eamemh6mp6h9old5omrssn@4ax.com> <38b0193a-eb86-4d6a-6292-f2203daff126@mccallumwhyman.com> <20170814154654.52d5d1d4@limapholos.matflo.wg> <20170815111313.0d368eaf@limapholos.matflo.wg> Message-ID: <3956bacd-2902-ea33-060b-252de9f97ca5@geldenhuys.co.uk> On 2017-08-15 18:29, Luca Olivetti via Lazarus wrote: > but for 3rd party libraries/components (e.g. > synapse comes to mind Then better start filing bug reports to all those 3rd party libraries and components - they have been abusing the system and will silently fail. Not to mention that FPC is almost at v3.0.4 and the new string changes were introduced in v3.0.0 already. 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 From mailinglists at geldenhuys.co.uk Tue Aug 15 21:16:00 2017 From: mailinglists at geldenhuys.co.uk (Graeme Geldenhuys) Date: Tue, 15 Aug 2017 20:16:00 +0100 Subject: [Lazarus] The new kid is growing up fast In-Reply-To: <6b24c127-5799-04bf-3537-2b919c37bfb5@lumino.de> References: <9f46c1f8-c4b1-846b-601b-e86e898bdac2@geldenhuys.co.uk> <6b24c127-5799-04bf-3537-2b919c37bfb5@lumino.de> Message-ID: <154ee5ce-15be-bd71-5a6d-87d6efad70a0@geldenhuys.co.uk> On 2017-08-15 12:35, Michael Schnell via Lazarus wrote: > How to compare it against Lazarus ? No idea - I've only been watching the CrossVCL videos as milestones get reached. I've never tried CrossVCL personally, and don't use Delphi personally either (since 2006). 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 From luca at wetron.es Tue Aug 15 21:22:10 2017 From: luca at wetron.es (Luca Olivetti) Date: Tue, 15 Aug 2017 21:22:10 +0200 Subject: [Lazarus] String vs WideString In-Reply-To: <3956bacd-2902-ea33-060b-252de9f97ca5@geldenhuys.co.uk> References: <20170812223247.73330e02@limapholos.matflo.wg> <20170812224956.4e624b23@limapholos.matflo.wg> <1ivuocdrq736eamemh6mp6h9old5omrssn@4ax.com> <38b0193a-eb86-4d6a-6292-f2203daff126@mccallumwhyman.com> <20170814154654.52d5d1d4@limapholos.matflo.wg> <20170815111313.0d368eaf@limapholos.matflo.wg> <3956bacd-2902-ea33-060b-252de9f97ca5@geldenhuys.co.uk> Message-ID: <66aa5516-1c29-f48e-1337-13abd8413e8d@wetron.es> El 15/08/17 a les 21:14, Graeme Geldenhuys via Lazarus ha escrit: > On 2017-08-15 18:29, Luca Olivetti via Lazarus wrote: >> but for 3rd party libraries/components (e.g. >> synapse comes to mind > > Then better start filing bug reports to all those 3rd party libraries > and components - they have been abusing the system and will silently > fail. Not to mention that FPC is almost at v3.0.4 and the new string > changes were introduced in v3.0.0 already. Wait a minute, why "abuse"? After all, before code aware strings, an ansistring could store any kind of arbitrary data with no problem and no conversion, and made it extremely easy to, e.g., add bytes to a buffer or find and extract data from the same buffer. *If* code that worked before (and dare I say without abusing the language) suddenly breaks, the bug is in the compiler and not in the library. (I remarked the "if" because I don't know if that's the case, according to Bo Berglund's experience it is) Bye -- Luca Olivetti Wetron Automation Technology http://www.wetron.es/ Tel. +34 93 5883004 (Ext.3010) Fax +34 93 5883007 From nc-gaertnma at netcologne.de Tue Aug 15 21:34:40 2017 From: nc-gaertnma at netcologne.de (Mattias Gaertner) Date: Tue, 15 Aug 2017 21:34:40 +0200 Subject: [Lazarus] String vs WideString In-Reply-To: <66aa5516-1c29-f48e-1337-13abd8413e8d@wetron.es> References: <20170812224956.4e624b23@limapholos.matflo.wg> <1ivuocdrq736eamemh6mp6h9old5omrssn@4ax.com> <38b0193a-eb86-4d6a-6292-f2203daff126@mccallumwhyman.com> <20170814154654.52d5d1d4@limapholos.matflo.wg> <20170815111313.0d368eaf@limapholos.matflo.wg> <3956bacd-2902-ea33-060b-252de9f97ca5@geldenhuys.co.uk> <66aa5516-1c29-f48e-1337-13abd8413e8d@wetron.es> Message-ID: <20170815213440.1c67b2b4@limapholos.matflo.wg> On Tue, 15 Aug 2017 21:22:10 +0200 Luca Olivetti via Lazarus wrote: >[...] > *If* code that worked before (and dare I say without abusing the > language) suddenly breaks, the bug is in the compiler and not in the > library. ... unless of course the incompatibility is deliberate and documented. In this case it is. Mattias From lazarus at kluug.net Tue Aug 15 21:38:34 2017 From: lazarus at kluug.net (Ondrej Pokorny) Date: Tue, 15 Aug 2017 21:38:34 +0200 Subject: [Lazarus] String vs WideString In-Reply-To: <20170815213440.1c67b2b4@limapholos.matflo.wg> References: <20170812224956.4e624b23@limapholos.matflo.wg> <1ivuocdrq736eamemh6mp6h9old5omrssn@4ax.com> <38b0193a-eb86-4d6a-6292-f2203daff126@mccallumwhyman.com> <20170814154654.52d5d1d4@limapholos.matflo.wg> <20170815111313.0d368eaf@limapholos.matflo.wg> <3956bacd-2902-ea33-060b-252de9f97ca5@geldenhuys.co.uk> <66aa5516-1c29-f48e-1337-13abd8413e8d@wetron.es> <20170815213440.1c67b2b4@limapholos.matflo.wg> Message-ID: On 15.08.2017 21:34, Mattias Gaertner via Lazarus wrote: > On Tue, 15 Aug 2017 21:22:10 +0200 > Luca Olivetti via Lazarus wrote: > >> [...] >> *If* code that worked before (and dare I say without abusing the >> language) suddenly breaks, the bug is in the compiler and not in the >> library. > ... unless of course the incompatibility is deliberate and documented. > In this case it is. Furthermore, if you use(d) strings for binary data, just replace old string for AnsiString/RawByteString (and Char for AnsiChar, PChar for PAnsiChar) and you are good to go. Annoying but no big deal. Ondrej From lazarus at kluug.net Tue Aug 15 21:40:18 2017 From: lazarus at kluug.net (Ondrej Pokorny) Date: Tue, 15 Aug 2017 21:40:18 +0200 Subject: [Lazarus] The new kid is growing up fast In-Reply-To: <9f46c1f8-c4b1-846b-601b-e86e898bdac2@geldenhuys.co.uk> References: <9f46c1f8-c4b1-846b-601b-e86e898bdac2@geldenhuys.co.uk> Message-ID: <14f27f69-e9d4-9620-4ba3-9608c59bfc44@kluug.net> Too bad that Eugene didn't decide to improve Lazarus Cocoa bindings :) Ondrej From luca at wetron.es Tue Aug 15 22:08:52 2017 From: luca at wetron.es (Luca Olivetti) Date: Tue, 15 Aug 2017 22:08:52 +0200 Subject: [Lazarus] String vs WideString In-Reply-To: References: <1ivuocdrq736eamemh6mp6h9old5omrssn@4ax.com> <38b0193a-eb86-4d6a-6292-f2203daff126@mccallumwhyman.com> <20170814154654.52d5d1d4@limapholos.matflo.wg> <20170815111313.0d368eaf@limapholos.matflo.wg> <3956bacd-2902-ea33-060b-252de9f97ca5@geldenhuys.co.uk> <66aa5516-1c29-f48e-1337-13abd8413e8d@wetron.es> <20170815213440.1c67b2b4@limapholos.matflo.wg> Message-ID: El 15/08/17 a les 21:38, Ondrej Pokorny via Lazarus ha escrit: > On 15.08.2017 21:34, Mattias Gaertner via Lazarus wrote: >> On Tue, 15 Aug 2017 21:22:10 +0200 >> Luca Olivetti via Lazarus wrote: >> >>> [...] >>> *If* code that worked before (and dare I say without abusing the >>> language) suddenly breaks, the bug is in the compiler and not in the >>> library. >> ... unless of course the incompatibility is deliberate and documented. >> In this case it is. > > Furthermore, if you use(d) strings for binary data, just replace old > string for AnsiString/RawByteString (and Char for AnsiChar, PChar for > PAnsiChar) and you are good to go. Annoying but no big deal. If that's all it's OK then, thank you. Bye -- Luca Olivetti Wetron Automation Technology http://www.wetron.es/ Tel. +34 93 5883004 (Ext.3010) Fax +34 93 5883007 From luca at wetron.es Tue Aug 15 22:09:43 2017 From: luca at wetron.es (Luca Olivetti) Date: Tue, 15 Aug 2017 22:09:43 +0200 Subject: [Lazarus] String vs WideString In-Reply-To: References: <1ivuocdrq736eamemh6mp6h9old5omrssn@4ax.com> <38b0193a-eb86-4d6a-6292-f2203daff126@mccallumwhyman.com> <20170814154654.52d5d1d4@limapholos.matflo.wg> <20170815111313.0d368eaf@limapholos.matflo.wg> <3956bacd-2902-ea33-060b-252de9f97ca5@geldenhuys.co.uk> <66aa5516-1c29-f48e-1337-13abd8413e8d@wetron.es> <20170815213440.1c67b2b4@limapholos.matflo.wg> Message-ID: <6120c6ba-400c-27e4-fe31-a9d45f3cfa66@wetron.es> El 15/08/17 a les 21:38, Ondrej Pokorny via Lazarus ha escrit: > On 15.08.2017 21:34, Mattias Gaertner via Lazarus wrote: >> On Tue, 15 Aug 2017 21:22:10 +0200 >> Luca Olivetti via Lazarus wrote: >> >>> [...] >>> *If* code that worked before (and dare I say without abusing the >>> language) suddenly breaks, the bug is in the compiler and not in the >>> library. >> ... unless of course the incompatibility is deliberate and documented. >> In this case it is. > > Furthermore, if you use(d) strings for binary data, just replace old > string for AnsiString/RawByteString (and Char for AnsiChar, PChar for > PAnsiChar) and you are good to go. Annoying but no big deal. If that's all it's OK then, thank you. Bye -- Luca Olivetti Wetron Automation Technology http://www.wetron.es/ Tel. +34 93 5883004 (Ext.3010) Fax +34 93 5883007 From luca at wetron.es Tue Aug 15 22:10:45 2017 From: luca at wetron.es (Luca Olivetti) Date: Tue, 15 Aug 2017 22:10:45 +0200 Subject: [Lazarus] String vs WideString In-Reply-To: References: <1ivuocdrq736eamemh6mp6h9old5omrssn@4ax.com> <38b0193a-eb86-4d6a-6292-f2203daff126@mccallumwhyman.com> <20170814154654.52d5d1d4@limapholos.matflo.wg> <20170815111313.0d368eaf@limapholos.matflo.wg> <3956bacd-2902-ea33-060b-252de9f97ca5@geldenhuys.co.uk> <66aa5516-1c29-f48e-1337-13abd8413e8d@wetron.es> <20170815213440.1c67b2b4@limapholos.matflo.wg> Message-ID: El 15/08/17 a les 22:08, Luca Olivetti ha escrit: > El 15/08/17 a les 21:38, Ondrej Pokorny via Lazarus ha escrit: >> On 15.08.2017 21:34, Mattias Gaertner via Lazarus wrote: >>> On Tue, 15 Aug 2017 21:22:10 +0200 >>> Luca Olivetti via Lazarus wrote: >>> >>>> [...] >>>> *If* code that worked before (and dare I say without abusing the >>>> language) suddenly breaks, the bug is in the compiler and not in the >>>> library. >>> ... unless of course the incompatibility is deliberate and documented. >>> In this case it is. >> >> Furthermore, if you use(d) strings for binary data, just replace old >> string for AnsiString/RawByteString (and Char for AnsiChar, PChar for >> PAnsiChar) and you are good to go. Annoying but no big deal. > > > If that's all it's OK then, thank you. Sorry for the direct reply, it was meant for the list. Bye -- Luca Olivetti Wetron Automation Technology http://www.wetron.es/ Tel. +34 93 5883004 (Ext.3010) Fax +34 93 5883007 From mailinglists at geldenhuys.co.uk Tue Aug 15 22:45:33 2017 From: mailinglists at geldenhuys.co.uk (Graeme Geldenhuys) Date: Tue, 15 Aug 2017 21:45:33 +0100 Subject: [Lazarus] String vs WideString In-Reply-To: <66aa5516-1c29-f48e-1337-13abd8413e8d@wetron.es> References: <20170812224956.4e624b23@limapholos.matflo.wg> <1ivuocdrq736eamemh6mp6h9old5omrssn@4ax.com> <38b0193a-eb86-4d6a-6292-f2203daff126@mccallumwhyman.com> <20170814154654.52d5d1d4@limapholos.matflo.wg> <20170815111313.0d368eaf@limapholos.matflo.wg> <3956bacd-2902-ea33-060b-252de9f97ca5@geldenhuys.co.uk> <66aa5516-1c29-f48e-1337-13abd8413e8d@wetron.es> Message-ID: <624223a6-e1ff-0006-0134-2777ffda4bc8@geldenhuys.co.uk> On 2017-08-15 20:22, Luca Olivetti via Lazarus wrote: > Wait a minute, why "abuse"? > After all, before code aware strings, an ansistring could store any kind > of arbitrary data with no problem and no conversion, and made it > extremely easy Just listen to what you are saying.... A string type and you want to store all kinds of non-string related data in that type. How is that not "abuse"??? Use a TBytes, TStream or other binary byte based storage mechanism. A string type was definitely not the right choice. 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 From luca at wetron.es Wed Aug 16 00:41:48 2017 From: luca at wetron.es (Luca Olivetti) Date: Wed, 16 Aug 2017 00:41:48 +0200 Subject: [Lazarus] String vs WideString In-Reply-To: <624223a6-e1ff-0006-0134-2777ffda4bc8@geldenhuys.co.uk> References: <20170812224956.4e624b23@limapholos.matflo.wg> <1ivuocdrq736eamemh6mp6h9old5omrssn@4ax.com> <38b0193a-eb86-4d6a-6292-f2203daff126@mccallumwhyman.com> <20170814154654.52d5d1d4@limapholos.matflo.wg> <20170815111313.0d368eaf@limapholos.matflo.wg> <3956bacd-2902-ea33-060b-252de9f97ca5@geldenhuys.co.uk> <66aa5516-1c29-f48e-1337-13abd8413e8d@wetron.es> <624223a6-e1ff-0006-0134-2777ffda4bc8@geldenhuys.co.uk> Message-ID: El 15/08/17 a les 22:45, Graeme Geldenhuys via Lazarus ha escrit: > On 2017-08-15 20:22, Luca Olivetti via Lazarus wrote: >> Wait a minute, why "abuse"? >> After all, before code aware strings, an ansistring could store any kind >> of arbitrary data with no problem and no conversion, and made it >> extremely easy > > > Just listen to what you are saying.... A string type and you want to > store all kinds of non-string related data in that type. How is that not > "abuse"??? Use a TBytes, TStream or other binary byte based storage > mechanism. A string type was definitely not the right choice. A "string" was just a handy container for bytes so I think it was the right choice for storing, er, bytes. Bye -- Luca Olivetti Wetron Automation Technology http://www.wetron.es/ Tel. +34 93 5883004 (Ext.3010) Fax +34 93 5883007 From mailinglists at geldenhuys.co.uk Wed Aug 16 01:17:32 2017 From: mailinglists at geldenhuys.co.uk (Graeme Geldenhuys) Date: Wed, 16 Aug 2017 00:17:32 +0100 Subject: [Lazarus] String vs WideString In-Reply-To: References: <1ivuocdrq736eamemh6mp6h9old5omrssn@4ax.com> <38b0193a-eb86-4d6a-6292-f2203daff126@mccallumwhyman.com> <20170814154654.52d5d1d4@limapholos.matflo.wg> <20170815111313.0d368eaf@limapholos.matflo.wg> <3956bacd-2902-ea33-060b-252de9f97ca5@geldenhuys.co.uk> <66aa5516-1c29-f48e-1337-13abd8413e8d@wetron.es> <624223a6-e1ff-0006-0134-2777ffda4bc8@geldenhuys.co.uk> Message-ID: On 2017-08-15 23:41, Luca Olivetti via Lazarus wrote: > A "string" was just a handy container for bytes so I think it was the > right choice for storing, er, bytes. The type "String" has always been an alias to another type, and could mean many things. eg: ShortString, AnsiString, and now UnicodeString. Making the assumption that it will always be a container for byte sized data was wrong. In hind sight, using TBytes or TMemoryStream and it would have been very clear that it is a storage container for byte sized data, and no automatic conversion (by the compiler) would be done to data stored in such containers. Don't worry though, you were not alone in making that wrong assumption. Many Delphi developers have made that mistake, and some are still making that mistake today. 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 From bo.berglund at gmail.com Wed Aug 16 07:53:11 2017 From: bo.berglund at gmail.com (Bo Berglund) Date: Wed, 16 Aug 2017 07:53:11 +0200 Subject: [Lazarus] String vs WideString References: <20170814154654.52d5d1d4@limapholos.matflo.wg> <20170815111313.0d368eaf@limapholos.matflo.wg> <3956bacd-2902-ea33-060b-252de9f97ca5@geldenhuys.co.uk> <66aa5516-1c29-f48e-1337-13abd8413e8d@wetron.es> Message-ID: On Tue, 15 Aug 2017 21:22:10 +0200, Luca Olivetti via Lazarus wrote: >(I remarked the "if" because I don't know if that's the case, according >to Bo Berglund's experience it is) Just to expand on my "experience" and the reason I posted: My work on converting the old program started back a couple of years when I went from Delphi 2007 (pre-unicode) to Delphi XE5 because we wanted the GUI to be translatable to non-western languages. But then all the communications functions (and these are many in this utility application) broke because they used strings as containers for the inherently binary serial data. So I followed advice on the Embarcadero forum to switch to AnsiString because that was really what the old string type was an alias for. I had no great insight in the inner workings of the string handling functions but I "knew" that AnsiString was a 1-byte per element and (unicode)string was now a 2-byte per element container. The fact that the code could alter the content of the AnsiString did not dawn on me at all. And the comm functions worked fine after the change (I tested a lot, but of course only on my English Win7 computer). Then some time ago there was a report of a failure of the new program version that only happened in Korea, China and Thailand. In the log files there was a very strange entry about finding an illegal command byte when sending a command to the equipment. It never triggered when I debugged the problem, for me and my collegues it worked flawlessly. So I had to add more logging and found that the problem arose when the outgoing command was built. A certain 1-byte command was then expanded to 2 bytes with the wrong first byte! The commands in the protocol are the first byte of the data of a telegram and they are in range $C0..$E9. When one of these (I don't now remember exactly which one) was used in an assignment to the AnsiString buffer it was converted to $3F + something that was never logged and the operation failed because the equipment could not decode the command. So I asked again on the forum and was steered towards RawByteString because presumably that container would disallow conversions. And when I changed this and sent a new version to the distributor in Korea the problem was seemingly gone. Based on this experience I wanted to alert the OP of the fact that using AnsiString instead of string is not a cure-all for binary data, you need to fix the codepage too, which is what the RawByteString does for you.... But I have now moved on and replaced all comm related containers with TBytes including modifying the serial component we have used. (With some help from Remy Lebeau). -- Bo Berglund Developer in Sweden From bo.berglund at gmail.com Wed Aug 16 08:01:24 2017 From: bo.berglund at gmail.com (Bo Berglund) Date: Wed, 16 Aug 2017 08:01:24 +0200 Subject: [Lazarus] String vs WideString References: <20170814154654.52d5d1d4@limapholos.matflo.wg> <20170815111313.0d368eaf@limapholos.matflo.wg> <3956bacd-2902-ea33-060b-252de9f97ca5@geldenhuys.co.uk> <66aa5516-1c29-f48e-1337-13abd8413e8d@wetron.es> Message-ID: On Wed, 16 Aug 2017 07:53:11 +0200, Bo Berglund via Lazarus wrote: >But I have now moved on and replaced all comm related containers with >TBytes including modifying the serial component we have used. >(With some help from Remy Lebeau). I forgot to mention that the problem area is located inside a non-GUI class file for handling the communications, and this file is also used in some programs written in FPC for Raspberry Pi target computers. I.e. Linux and the reason for going to FPC. So I want it to be both FPC and Delphi compatible... -- Bo Berglund Developer in Sweden From mschnell at lumino.de Wed Aug 16 10:38:11 2017 From: mschnell at lumino.de (Michael Schnell) Date: Wed, 16 Aug 2017 10:38:11 +0200 Subject: [Lazarus] The new kid is growing up fast In-Reply-To: <14f27f69-e9d4-9620-4ba3-9608c59bfc44@kluug.net> References: <9f46c1f8-c4b1-846b-601b-e86e898bdac2@geldenhuys.co.uk> <14f27f69-e9d4-9620-4ba3-9608c59bfc44@kluug.net> Message-ID: <4cce6562-1fa6-b574-6622-34ac2b47837b@lumino.de> On 15.08.2017 21:40, Ondrej Pokorny via Lazarus wrote: > Too bad that Eugene didn't decide to improve Lazarus Cocoa bindings :) Does he use fpc as a compiler ? -Michael From mschnell at lumino.de Wed Aug 16 10:43:18 2017 From: mschnell at lumino.de (Michael Schnell) Date: Wed, 16 Aug 2017 10:43:18 +0200 Subject: [Lazarus] String vs WideString In-Reply-To: References: <20170812224956.4e624b23@limapholos.matflo.wg> <1ivuocdrq736eamemh6mp6h9old5omrssn@4ax.com> <38b0193a-eb86-4d6a-6292-f2203daff126@mccallumwhyman.com> <20170814154654.52d5d1d4@limapholos.matflo.wg> <20170815111313.0d368eaf@limapholos.matflo.wg> <49d88133-d578-d80c-c080-58b635602054@lumino.de> Message-ID: On 15.08.2017 19:18, Graeme Geldenhuys via Lazarus wrote: > > Why can't that be changed to a UnicodeString or UTF8String IMHO, any implementation of TStrings that forces a conversion (just because the class uses TStrings and not due to a logical demand), is a contradiction to providing code aware strings at all. -Michael From mschnell at lumino.de Wed Aug 16 10:47:37 2017 From: mschnell at lumino.de (Michael Schnell) Date: Wed, 16 Aug 2017 10:47:37 +0200 Subject: [Lazarus] String vs WideString In-Reply-To: References: <20170812223247.73330e02@limapholos.matflo.wg> <20170812224956.4e624b23@limapholos.matflo.wg> <1ivuocdrq736eamemh6mp6h9old5omrssn@4ax.com> <38b0193a-eb86-4d6a-6292-f2203daff126@mccallumwhyman.com> <20170814154654.52d5d1d4@limapholos.matflo.wg> <20170815111313.0d368eaf@limapholos.matflo.wg> Message-ID: On 15.08.2017 19:29, Luca Olivetti via Lazarus wrote: > I has worked extremely well and reliably until fpc 2.6.4 (i.e. with > string=ansistring). > Does it not work in 3.x? I understand that storing uncoded Bytes in UTF8-Strings (hence in fpc) works as good as it always had, as long as all strings are defined with the same code branding as TSrings (and friends) is (i.e. UTF8), because there never will be a conversion. But it does not work in Delphi, as here TStrings is defined to be UTF-16. -Michael From mschnell at lumino.de Wed Aug 16 10:51:52 2017 From: mschnell at lumino.de (Michael Schnell) Date: Wed, 16 Aug 2017 10:51:52 +0200 Subject: [Lazarus] String vs WideString In-Reply-To: References: <1ivuocdrq736eamemh6mp6h9old5omrssn@4ax.com> <38b0193a-eb86-4d6a-6292-f2203daff126@mccallumwhyman.com> <20170814154654.52d5d1d4@limapholos.matflo.wg> <20170815111313.0d368eaf@limapholos.matflo.wg> <3956bacd-2902-ea33-060b-252de9f97ca5@geldenhuys.co.uk> <66aa5516-1c29-f48e-1337-13abd8413e8d@wetron.es> <20170815213440.1c67b2b4@limapholos.matflo.wg> Message-ID: <03c25667-0667-3a28-1d36-abe66fa34758@lumino.de> On 15.08.2017 21:38, Ondrej Pokorny via Lazarus wrote: > > Furthermore, if you use(d) strings for binary data, just replace old > string for AnsiString/RawByteString (and Char for AnsiChar, PChar for > PAnsiChar) and you are good to go. Annoying but no big deal. This only works if all tools that you use do the same. And a major tool for handling strings is TStrings and it's siblings. You hardly an avoid using same. -Michael From nc-gaertnma at netcologne.de Wed Aug 16 10:58:13 2017 From: nc-gaertnma at netcologne.de (Mattias Gaertner) Date: Wed, 16 Aug 2017 10:58:13 +0200 Subject: [Lazarus] String vs WideString In-Reply-To: References: <20170812224956.4e624b23@limapholos.matflo.wg> <1ivuocdrq736eamemh6mp6h9old5omrssn@4ax.com> <38b0193a-eb86-4d6a-6292-f2203daff126@mccallumwhyman.com> <20170814154654.52d5d1d4@limapholos.matflo.wg> <20170815111313.0d368eaf@limapholos.matflo.wg> Message-ID: <20170816105813.74534c28@limapholos.matflo.wg> On Wed, 16 Aug 2017 10:47:37 +0200 Michael Schnell via Lazarus wrote: > On 15.08.2017 19:29, Luca Olivetti via Lazarus wrote: > > I has worked extremely well and reliably until fpc 2.6.4 (i.e. with > > string=ansistring). > > Does it not work in 3.x? > I understand that storing uncoded Bytes in UTF8-Strings (hence in fpc) > works as good as it always had, as long as all strings are defined with > the same code branding as TSrings (and friends) is (i.e. UTF8), because > there never will be a conversion. > > But it does not work in Delphi, as here TStrings is defined to be UTF-16. This thread is going out of topic. Please start a new thread if you want to discuss Delphi strings. Mattias From juha.manninen62 at gmail.com Wed Aug 16 10:59:20 2017 From: juha.manninen62 at gmail.com (Juha Manninen) Date: Wed, 16 Aug 2017 11:59:20 +0300 Subject: [Lazarus] String vs WideString In-Reply-To: References: <20170814154654.52d5d1d4@limapholos.matflo.wg> <20170815111313.0d368eaf@limapholos.matflo.wg> <3956bacd-2902-ea33-060b-252de9f97ca5@geldenhuys.co.uk> <66aa5516-1c29-f48e-1337-13abd8413e8d@wetron.es> Message-ID: On Wed, Aug 16, 2017 at 8:53 AM, Bo Berglund via Lazarus wrote: > Based on this experience I wanted to alert the OP of the fact that > using AnsiString instead of string is not a cure-all for binary data, > you need to fix the codepage too, which is what the RawByteString does > for you.... Bo, everybody has known for decades that AnsiString is not for binary data. Why do you proclaim it as a new discovery? The OP's problem was completely different. It was about text encoding. TBytes is clearly the right choice for your binary data, but this discussion is not about binary data! What means "AnsiString instead of string"? String is typically an alias for AnsiString. Your sentence about RawByteString is also wrong. There is no automatic codepage conversion for RawByteString. Juha From mschnell at lumino.de Wed Aug 16 11:01:26 2017 From: mschnell at lumino.de (Michael Schnell) Date: Wed, 16 Aug 2017 11:01:26 +0200 Subject: [Lazarus] String vs WideString In-Reply-To: <624223a6-e1ff-0006-0134-2777ffda4bc8@geldenhuys.co.uk> References: <20170812224956.4e624b23@limapholos.matflo.wg> <1ivuocdrq736eamemh6mp6h9old5omrssn@4ax.com> <38b0193a-eb86-4d6a-6292-f2203daff126@mccallumwhyman.com> <20170814154654.52d5d1d4@limapholos.matflo.wg> <20170815111313.0d368eaf@limapholos.matflo.wg> <3956bacd-2902-ea33-060b-252de9f97ca5@geldenhuys.co.uk> <66aa5516-1c29-f48e-1337-13abd8413e8d@wetron.es> <624223a6-e1ff-0006-0134-2777ffda4bc8@geldenhuys.co.uk> Message-ID: <734ab095-18ff-36c5-7a6e-e35f2e27d8cd@lumino.de> On 15.08.2017 22:45, Graeme Geldenhuys via Lazarus wrote: > How is that not "abuse"??? IMHO it's a major shortcoming to define "string" as "printable text". In fact the name "String" does not suggest this at all. A "string" in my understanding just is a sequence of similar "things". > A string type was definitely not the right choice. Notwithstanding the discussion about the mere wording, this only would hold, if the system would provide a differently named non "printable text" basic type that comes with the features needed for such usage: reference counting, lazy copy, simple operators for concatenating and element extraction and replacement, built-in function for substring locating, ... -Michael From michael at freepascal.org Wed Aug 16 11:06:41 2017 From: michael at freepascal.org (Michael Van Canneyt) Date: Wed, 16 Aug 2017 11:06:41 +0200 (CEST) Subject: [Lazarus] String vs WideString In-Reply-To: <734ab095-18ff-36c5-7a6e-e35f2e27d8cd@lumino.de> References: <1ivuocdrq736eamemh6mp6h9old5omrssn@4ax.com> <38b0193a-eb86-4d6a-6292-f2203daff126@mccallumwhyman.com> <20170814154654.52d5d1d4@limapholos.matflo.wg> <20170815111313.0d368eaf@limapholos.matflo.wg> <3956bacd-2902-ea33-060b-252de9f97ca5@geldenhuys.co.uk> <66aa5516-1c29-f48e-1337-13abd8413e8d@wetron.es> <624223a6-e1ff-0006-0134-2777ffda4bc8@geldenhuys.co.uk> <734ab095-18ff-36c5-7a6e-e35f2e27d8cd@lumino.de> Message-ID: On Wed, 16 Aug 2017, Michael Schnell via Lazarus wrote: > On 15.08.2017 22:45, Graeme Geldenhuys via Lazarus wrote: >> How is that not "abuse"??? > IMHO it's a major shortcoming to define "string" as "printable text". On the contrary. That is exactly what it means. Anything else is just a collection of bytes. Michael. From mailinglists at geldenhuys.co.uk Wed Aug 16 11:08:23 2017 From: mailinglists at geldenhuys.co.uk (Graeme Geldenhuys) Date: Wed, 16 Aug 2017 10:08:23 +0100 Subject: [Lazarus] String vs WideString In-Reply-To: References: <20170812224956.4e624b23@limapholos.matflo.wg> <1ivuocdrq736eamemh6mp6h9old5omrssn@4ax.com> <38b0193a-eb86-4d6a-6292-f2203daff126@mccallumwhyman.com> <20170814154654.52d5d1d4@limapholos.matflo.wg> <20170815111313.0d368eaf@limapholos.matflo.wg> <49d88133-d578-d80c-c080-58b635602054@lumino.de> Message-ID: <762d5869-d011-a91e-6571-317d4ad01c45@geldenhuys.co.uk> On 2017-08-16 09:43, Michael Schnell via Lazarus wrote: > IMHO, any implementation of TStrings that forces a conversion (just > because the class uses TStrings and not due to a logical demand), is a > contradiction to providing code aware strings at all. But in FPC 3.x (using modern compiler modes - not TP or Mac) String = UnicodeString. So it makes sense that TStrings should use UnicodeString internally to store its data. The Unicode standard is also the only standard that can support any language. So all Windows code-pages can be supported with the single UnicodeString type. Are you suggesting that internally TStrings should have different storage for all possible languages, or some RawByteString type? So if you load some non-Latin code-page text internally it still stores that text as that non-Latin bytes? That would just over-complicate the TStrings class. FPC is moving towards UnicodeString being used internally for everything in the RTL, so why must TStrings be any different. 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 From mschnell at lumino.de Wed Aug 16 11:09:17 2017 From: mschnell at lumino.de (Michael Schnell) Date: Wed, 16 Aug 2017 11:09:17 +0200 Subject: [Lazarus] String vs WideString In-Reply-To: <20170816105813.74534c28@limapholos.matflo.wg> References: <20170812224956.4e624b23@limapholos.matflo.wg> <1ivuocdrq736eamemh6mp6h9old5omrssn@4ax.com> <38b0193a-eb86-4d6a-6292-f2203daff126@mccallumwhyman.com> <20170814154654.52d5d1d4@limapholos.matflo.wg> <20170815111313.0d368eaf@limapholos.matflo.wg> <20170816105813.74534c28@limapholos.matflo.wg> Message-ID: <0e055284-efd9-6fda-68ed-f42770b05b0d@lumino.de> On 16.08.2017 10:58, Mattias Gaertner via Lazarus wrote: > This thread is going out of topic. > Please start a new thread if you want to discuss Delphi strings. You can't discuss fpc's string problems without mentioning Delphi, as they are a direct consequence as well of Delphi-compatibility as of Delphi-incompatibility. -Michael From juha.manninen62 at gmail.com Wed Aug 16 11:12:20 2017 From: juha.manninen62 at gmail.com (Juha Manninen) Date: Wed, 16 Aug 2017 12:12:20 +0300 Subject: [Lazarus] String vs WideString In-Reply-To: References: <20170812223247.73330e02@limapholos.matflo.wg> <20170812224956.4e624b23@limapholos.matflo.wg> <1ivuocdrq736eamemh6mp6h9old5omrssn@4ax.com> <38b0193a-eb86-4d6a-6292-f2203daff126@mccallumwhyman.com> Message-ID: On Mon, Aug 14, 2017 at 4:11 PM, Marcos Douglas B. Santos via Lazarus wrote: > Unicode everywhere and you using AnsiString and doing everything... > Now I'm confused. Yes, please read: http://wiki.freepascal.org/Unicode_Support_in_Lazarus I have advertised it so much that some people are already irritated, but maybe you missed it so far. > FPC and Lazarus claim they are cross-platform — this is a fact — and > because that, IMHO, both should be use in only one way in every > system, don't you think? Yes, and that's how it works. > This is a ugly trick... but I understood what you mean. This was about the explicit temporary UnicodeString variable for WinAPI call parameters. No, it is not ugly, the code remains 100% compatible with Delphi. Please remember also that direct WinAPI call are not needed in cross-platform code. Juha From mschnell at lumino.de Wed Aug 16 11:12:40 2017 From: mschnell at lumino.de (Michael Schnell) Date: Wed, 16 Aug 2017 11:12:40 +0200 Subject: [Lazarus] String vs WideString In-Reply-To: <01f722fe-3e5d-eb63-e7cf-3f2c369e7529@windstream.net> References: <20170812223247.73330e02@limapholos.matflo.wg> <20170812224956.4e624b23@limapholos.matflo.wg> <1ivuocdrq736eamemh6mp6h9old5omrssn@4ax.com> <38b0193a-eb86-4d6a-6292-f2203daff126@mccallumwhyman.com> <20170814154654.52d5d1d4@limapholos.matflo.wg> <20170815111313.0d368eaf@limapholos.matflo.wg> <01f722fe-3e5d-eb63-e7cf-3f2c369e7529@windstream.net> Message-ID: <61991de6-49ef-bb30-d5f2-dba7a0242e1b@lumino.de> On 15.08.2017 19:53, wkitty42--- via Lazarus wrote: > what if 3 and 4 byte characters are required? will they also work in > UnicodeStrings? UTF-8 and UTF-16 are just encoding variants for 32 bit Unicode "characters", storing them in n (or 2*n) Bytes according to a simple scheme. -Michael From mschnell at lumino.de Wed Aug 16 11:26:46 2017 From: mschnell at lumino.de (Michael Schnell) Date: Wed, 16 Aug 2017 11:26:46 +0200 Subject: [Lazarus] String vs WideString In-Reply-To: <20170815183325.10ea1a0f@limapholos.matflo.wg> References: <20170812224956.4e624b23@limapholos.matflo.wg> <1ivuocdrq736eamemh6mp6h9old5omrssn@4ax.com> <38b0193a-eb86-4d6a-6292-f2203daff126@mccallumwhyman.com> <20170814154654.52d5d1d4@limapholos.matflo.wg> <20170815145300.3deb1062@limapholos.matflo.wg> <7e106689-cd91-8fda-1dc6-f0273e5cd07d@lumino.de> <20170815183325.10ea1a0f@limapholos.matflo.wg> Message-ID: On 15.08.2017 18:33, Mattias Gaertner via Lazarus wrote: > Do you propose a string without the array operator [] ? I don't understand what you mean by this. Of course an appropriate "char" type for each string encoding brand could to be provided, hence a "CP_QWord Char" as an alias or a QWord. (Please keep in mind that in that paper (as explicitly pointed out) "String" is not a synonym for "printable text" but for "sequence of similar things". And here of course (at least in a 64 bit system) it's extremely appropriate to allow for 64 bit elements. And of course this is just a suggestion that could solve a certain class of problems but needs a big effort to do and verify the modifications in the compiler and the libraries.) -Michael From nc-gaertnma at netcologne.de Wed Aug 16 11:32:16 2017 From: nc-gaertnma at netcologne.de (Mattias Gaertner) Date: Wed, 16 Aug 2017 11:32:16 +0200 Subject: [Lazarus] String vs WideString In-Reply-To: <0e055284-efd9-6fda-68ed-f42770b05b0d@lumino.de> References: <20170812224956.4e624b23@limapholos.matflo.wg> <1ivuocdrq736eamemh6mp6h9old5omrssn@4ax.com> <38b0193a-eb86-4d6a-6292-f2203daff126@mccallumwhyman.com> <20170814154654.52d5d1d4@limapholos.matflo.wg> <20170815111313.0d368eaf@limapholos.matflo.wg> <20170816105813.74534c28@limapholos.matflo.wg> <0e055284-efd9-6fda-68ed-f42770b05b0d@lumino.de> Message-ID: <20170816113216.557a1081@limapholos.matflo.wg> On Wed, 16 Aug 2017 11:09:17 +0200 Michael Schnell via Lazarus wrote: > On 16.08.2017 10:58, Mattias Gaertner via Lazarus wrote: > > This thread is going out of topic. > > Please start a new thread if you want to discuss Delphi strings. > You can't discuss fpc's string problems without mentioning Delphi, as > they are a direct consequence as well of Delphi-compatibility as of > Delphi-incompatibility. The original post was about a string conversion warning. Anyone who wants to discuss the grand picture of strings in FPC for the millionth time should start a new topic. Mattias From mschnell at lumino.de Wed Aug 16 11:33:04 2017 From: mschnell at lumino.de (Michael Schnell) Date: Wed, 16 Aug 2017 11:33:04 +0200 Subject: [Lazarus] String vs WideString In-Reply-To: <762d5869-d011-a91e-6571-317d4ad01c45@geldenhuys.co.uk> References: <1ivuocdrq736eamemh6mp6h9old5omrssn@4ax.com> <38b0193a-eb86-4d6a-6292-f2203daff126@mccallumwhyman.com> <20170814154654.52d5d1d4@limapholos.matflo.wg> <20170815111313.0d368eaf@limapholos.matflo.wg> <49d88133-d578-d80c-c080-58b635602054@lumino.de> <762d5869-d011-a91e-6571-317d4ad01c45@geldenhuys.co.uk> Message-ID: <28f6d572-59ea-2dfb-4566-5c39b9da00c4@lumino.de> On 16.08.2017 11:08, Graeme Geldenhuys via Lazarus wrote: > So it makes sense that TStrings should use UnicodeString internally to > store its data. The Unicode standard is also the only standard that > can support any language. But in fact "Unicode" is just a universal standard defining 64 bit entities. The encoding of those varies: UTF-8, UTF-16 high byte first, UTF-16 low byte first, 64 bit low byte first, 64 bit high byte first, .... fpc and Delphi do support several of those as a string encoding (and with that crating any number of problems). -Michael From mschnell at lumino.de Wed Aug 16 11:36:41 2017 From: mschnell at lumino.de (Michael Schnell) Date: Wed, 16 Aug 2017 11:36:41 +0200 Subject: [Lazarus] String vs WideString In-Reply-To: <762d5869-d011-a91e-6571-317d4ad01c45@geldenhuys.co.uk> References: <1ivuocdrq736eamemh6mp6h9old5omrssn@4ax.com> <38b0193a-eb86-4d6a-6292-f2203daff126@mccallumwhyman.com> <20170814154654.52d5d1d4@limapholos.matflo.wg> <20170815111313.0d368eaf@limapholos.matflo.wg> <49d88133-d578-d80c-c080-58b635602054@lumino.de> <762d5869-d011-a91e-6571-317d4ad01c45@geldenhuys.co.uk> Message-ID: On 16.08.2017 11:08, Graeme Geldenhuys via Lazarus wrote: > Are you suggesting that internally TStrings should have different > storage for all possible languages, Not at all. In the said paper I point out that a new fully dynamical string encoding brand would be introduced and same is used for TStrings. Everything else will not provide an improvement of the class of problems under discussion since years. -Michael (knowing that this will never happen) From mschnell at lumino.de Wed Aug 16 11:41:10 2017 From: mschnell at lumino.de (Michael Schnell) Date: Wed, 16 Aug 2017 11:41:10 +0200 Subject: [Lazarus] String vs WideString In-Reply-To: <20170816113216.557a1081@limapholos.matflo.wg> References: <1ivuocdrq736eamemh6mp6h9old5omrssn@4ax.com> <38b0193a-eb86-4d6a-6292-f2203daff126@mccallumwhyman.com> <20170814154654.52d5d1d4@limapholos.matflo.wg> <20170815111313.0d368eaf@limapholos.matflo.wg> <20170816105813.74534c28@limapholos.matflo.wg> <0e055284-efd9-6fda-68ed-f42770b05b0d@lumino.de> <20170816113216.557a1081@limapholos.matflo.wg> Message-ID: <518214d9-4762-e586-133e-59cf4c34486d@lumino.de> On 16.08.2017 11:32, Mattias Gaertner via Lazarus wrote: > Anyone who wants to discuss the grand picture of strings in FPC for the millionth time should start a new topic. Right you are. And it will be by far too late and futile, anyway, because of the reasons discussed a million times. -Michael From nc-gaertnma at netcologne.de Wed Aug 16 11:51:14 2017 From: nc-gaertnma at netcologne.de (Mattias Gaertner) Date: Wed, 16 Aug 2017 11:51:14 +0200 Subject: [Lazarus] dynamic string proposal Message-ID: <20170816115114.06d361db@limapholos.matflo.wg> Starting a new thread for a new topic. It's not that hard. On Wed, 16 Aug 2017 11:26:46 +0200 Michael Schnell via Lazarus wrote: > On 15.08.2017 18:33, Mattias Gaertner via Lazarus wrote: > > Do you propose a string without the array operator [] ? > I don't understand what you mean by this. Every Delphi/FPC type has a bunch of operators. Strings support :=, =, <>, >=, <= and [] for read and write. When you propose a new string type "dynamicstring" you have to define these operators. Otherwise your proposal is not a string, but just a magic unicorn. > Of course an appropriate "char" type for each string encoding brand > could to be provided, hence a "CP_QWord Char" as an alias or a QWord. There is no QWord codepage. That would be confusing. > (Please keep in mind that in that paper (as explicitly pointed out) > "String" is not a synonym for "printable text" but for "sequence of > similar things". And here of course (at least in a 64 bit system) it's > extremely appropriate to allow for 64 bit elements. And of course this > is just a suggestion that could solve a certain class of problems but > needs a big effort to do and verify the modifications in the compiler > and the libraries.) Mattias From nc-gaertnma at netcologne.de Wed Aug 16 11:55:04 2017 From: nc-gaertnma at netcologne.de (Mattias Gaertner) Date: Wed, 16 Aug 2017 11:55:04 +0200 Subject: [Lazarus] String vs WideString In-Reply-To: <28f6d572-59ea-2dfb-4566-5c39b9da00c4@lumino.de> References: <1ivuocdrq736eamemh6mp6h9old5omrssn@4ax.com> <38b0193a-eb86-4d6a-6292-f2203daff126@mccallumwhyman.com> <20170814154654.52d5d1d4@limapholos.matflo.wg> <20170815111313.0d368eaf@limapholos.matflo.wg> <49d88133-d578-d80c-c080-58b635602054@lumino.de> <762d5869-d011-a91e-6571-317d4ad01c45@geldenhuys.co.uk> <28f6d572-59ea-2dfb-4566-5c39b9da00c4@lumino.de> Message-ID: <20170816115504.3bb197c5@limapholos.matflo.wg> On Wed, 16 Aug 2017 11:33:04 +0200 Michael Schnell via Lazarus wrote: >[...] > But in fact "Unicode" is just a universal standard defining 64 bit > entities. No. 1,114,112 possible code points need at most 21 bits. Due to encoding at most 32bit. Mattias From juha.manninen62 at gmail.com Wed Aug 16 12:05:43 2017 From: juha.manninen62 at gmail.com (Juha Manninen) Date: Wed, 16 Aug 2017 13:05:43 +0300 Subject: [Lazarus] String vs WideString In-Reply-To: References: <20170812223247.73330e02@limapholos.matflo.wg> <20170812224956.4e624b23@limapholos.matflo.wg> <1ivuocdrq736eamemh6mp6h9old5omrssn@4ax.com> <38b0193a-eb86-4d6a-6292-f2203daff126@mccallumwhyman.com> <20170814154654.52d5d1d4@limapholos.matflo.wg> Message-ID: On Mon, Aug 14, 2017 at 4:21 PM, Tony Whyman via Lazarus wrote: > UTF-16/Unicode can only store 65,536 characters while the Unicode standard > (that covers UTF8 as well) defines 136,755 characters. > UTF-16/Unicode's main advantage seems to be for rapid indexing of large > strings. That shows complete ignorance from your side about Unicode. You consider UTF-16 as a fixed-width encoding. :( Unfortunately many other programmers had the same wrong idea or they were just lazy. The result anyway is a lot of broken UTF-16 code out there. On Tue, Aug 15, 2017 at 12:15 PM, Tony Whyman via Lazarus wrote: > If a topic keeps on being discussed after 10+ years of argument, the reason > is usually either (a) the problem and its solution have not been documented > properly, or (b) the outcome is an unsatisfactory compromise. Or (c) The people discussing are ignorant about the topic. > I went back and read the wiki article you mentioned and was no more the > wiser as to why the current mess exists. Is it really no more than because > Delphi continues to screw up in this area, so must FPC? The body of the > article appears to be a set of notes - not necessarily wrong in themselves > but lacking the background and context needed to explain why it is like it is. Hmmm... Originally the page was a mess because it had lots of irrelevant background info about the old obsolete LCL Unicode support. Text was added by many people but none was removed. Finally I cleaned the page. It now has most relevant info at the top and then special cases and technical details later. I am rather happy with the page now, it explains how to use Unicode with Lazarus as clearly as possible. However I am willing to improve it. What kind of background and context would you need? > 1. Stop using the term "Unicode". You can stop using it. No problem. For others however it is a well defined international standard. See: https://en.wikipedia.org/wiki/Unicode > 2. Clean up the char type. > ... > Why shouldn't there be a single char type that intuitively represents > a single character regardless of how many bytes are used to represent it. What do you mean by "a single character"? A "character" in Unicode can mean about 7 different things. Which one is your pick? This question is for everybody in this thread who used the word "character". > Yes, in a world where we have to live with UTF8, UTF16, UTF32, legacy code > pages and Chinese variations on UTF8, that means that dynamic attributes > have to be included in the type. But isn't that the only way to have > consistent and intuitive character handling? What do you mean? Chinese don't have a variation of UTF8. UTF8 is global unambiguous encoding standard, part of Unicode. The fundamental problem is that you want to hide the complexity of Unicode by some magic String type of a compiler. It is not possible. Unicode remains complex but the complexity is NOT in encodings! No, a codepoint's encoding is the easy part. For example I was easily able to create a unit to support encoding agnostic code. See unit LazUnicode in package LazUtils. The complexity is elsewhere: - "Character" composed of codepoints in precomposed and decomposed (normalized) forms. - Compare and sort text based on locale. - Uppercase / Lowercase rules based on locale. - Glyphs - Graphemes - etc. I must admit I don't understand well those complex parts. I do understand codeunits and codepoints, and I understand they are the easy part. Juha From badsectoracula at gmail.com Wed Aug 16 12:08:06 2017 From: badsectoracula at gmail.com (Kostas Michalopoulos) Date: Wed, 16 Aug 2017 13:08:06 +0300 Subject: [Lazarus] OpenGL 4.6 bindings and generator Message-ID: Hi all, After finding the OpenGL bindings that come with Lazarus a bit on the ancient side of things (i think it only supports up to 4.0? Also there is a 4.3 version loading function but only seems to call 3.3's loader - ignoring 4.0 - and loads only a single extension) and never really liking the global functions of pointers approach (if nothing else it makes the autocompletion in the IDE a bit annoying) i decided to make some brand new bindings. I wrote a parser for Khronos' XML spec (gl.xml) that generates the appropriate interface and implementation. You only have to call LoadGLProcs after you have a context ready and it tries to load everything it knows of. Instead of Load_some_extension you get a global Has_some_extension variable (these are initialized via LoadGLProcs too). As a bonus you get a HasExtension function as well as an AllExtensions array of strings. Btw it is not a drop in replacement for GL/GLext/GLotherstuff, although you can use it with the OpenGL control that comes with Lazarus and most likely it is compatible as long as you don't use it from the same unit (since all they do is call the driver stuff anyway) and you initialize both using the same context (since different contexts might give different functions). You can find the code as well as a pregenerated "OpenGL" unit at: http://runtimeterror.com/rep/gl2unit/index At the moment only Windows is supported, but soon i'll add Linux and eventually Mac OS X support (it should be around ~10 lines of code for each OS, hopefully). Also i have done minimal testing so there might be bugs :-). Kostas -------------- next part -------------- An HTML attachment was scrubbed... URL: From mschnell at lumino.de Wed Aug 16 12:15:47 2017 From: mschnell at lumino.de (Michael Schnell) Date: Wed, 16 Aug 2017 12:15:47 +0200 Subject: [Lazarus] String vs WideString In-Reply-To: <20170816115504.3bb197c5@limapholos.matflo.wg> References: <38b0193a-eb86-4d6a-6292-f2203daff126@mccallumwhyman.com> <20170814154654.52d5d1d4@limapholos.matflo.wg> <20170815111313.0d368eaf@limapholos.matflo.wg> <49d88133-d578-d80c-c080-58b635602054@lumino.de> <762d5869-d011-a91e-6571-317d4ad01c45@geldenhuys.co.uk> <28f6d572-59ea-2dfb-4566-5c39b9da00c4@lumino.de> <20170816115504.3bb197c5@limapholos.matflo.wg> Message-ID: <2fffbf7a-6c6b-6b92-ada6-c602aeb97331@lumino.de> On 16.08.2017 11:55, Mattias Gaertner via Lazarus wrote: > 1,114,112 possible code points need at most 21 bits. Due to encoding > at most 32bit. Sorry. Typo. -Michael From juha.manninen62 at gmail.com Wed Aug 16 12:22:34 2017 From: juha.manninen62 at gmail.com (Juha Manninen) Date: Wed, 16 Aug 2017 13:22:34 +0300 Subject: [Lazarus] String vs WideString In-Reply-To: <61991de6-49ef-bb30-d5f2-dba7a0242e1b@lumino.de> References: <20170812223247.73330e02@limapholos.matflo.wg> <20170812224956.4e624b23@limapholos.matflo.wg> <1ivuocdrq736eamemh6mp6h9old5omrssn@4ax.com> <38b0193a-eb86-4d6a-6292-f2203daff126@mccallumwhyman.com> <20170814154654.52d5d1d4@limapholos.matflo.wg> <20170815111313.0d368eaf@limapholos.matflo.wg> <01f722fe-3e5d-eb63-e7cf-3f2c369e7529@windstream.net> <61991de6-49ef-bb30-d5f2-dba7a0242e1b@lumino.de> Message-ID: On Wed, Aug 16, 2017 at 12:12 PM, Michael Schnell via Lazarus wrote: > UTF-8 and UTF-16 are just encoding variants for 32 bit Unicode "characters", > storing them in n (or 2*n) Bytes according to a simple scheme. No, they are encodings for codepoints, not "characters" (whatever that means). Michael Schnell, your posts are completely out of topic. Unicode related topics clearly pull you like a magnet and then you loose all control and start to proclaim your grand plan for a string revamp. It can continue for months as we remember from past years. You should stop writing in this thread now. I agree with Mattias. Juha From mschnell at lumino.de Wed Aug 16 12:24:55 2017 From: mschnell at lumino.de (Michael Schnell) Date: Wed, 16 Aug 2017 12:24:55 +0200 Subject: [Lazarus] dynamic string proposal In-Reply-To: <20170816115114.06d361db@limapholos.matflo.wg> References: <20170816115114.06d361db@limapholos.matflo.wg> Message-ID: <5fb059ce-6d78-14e2-614a-e30ec476dd28@lumino.de> On 16.08.2017 11:51, Mattias Gaertner via Lazarus wrote: > Every Delphi/FPC type has a bunch of operators. Strings support :=, =, > <>, >=, <= and [] for read and write. > When you propose a new string type "dynamicstring" you have to define these operators. That is easily doable. The definition of := is discussed in the paper. (Only for := there is no accessible encoding definition for the left operand.) If the encoding branding is one of those that already exist, the current definition is used. For "new" encoding brandings, such as CP_Byte, CP_Word, CP_DWord, CP_QWord, the working of the operators is obvious. It somebody tries to compare a printable Text string with a string of binary elements, maybe the behavior is undefined. > There is no QWord codepage. That would be confusing. Of course the term "Codepage" Embarcadero chose for the encoding identification is misleading in this context. That is why in the said paper it's called "encoding style" (which is not a really appropriate wording, either, but hey, it's just an initial suggestion and not yet a final documentation, and it had been clear from the beginning that it's in vain, anyway. ) -Michael From mschnell at lumino.de Wed Aug 16 12:26:48 2017 From: mschnell at lumino.de (Michael Schnell) Date: Wed, 16 Aug 2017 12:26:48 +0200 Subject: [Lazarus] String vs WideString In-Reply-To: References: <20170812224956.4e624b23@limapholos.matflo.wg> <1ivuocdrq736eamemh6mp6h9old5omrssn@4ax.com> <38b0193a-eb86-4d6a-6292-f2203daff126@mccallumwhyman.com> <20170814154654.52d5d1d4@limapholos.matflo.wg> <20170815111313.0d368eaf@limapholos.matflo.wg> <01f722fe-3e5d-eb63-e7cf-3f2c369e7529@windstream.net> <61991de6-49ef-bb30-d5f2-dba7a0242e1b@lumino.de> Message-ID: On 16.08.2017 12:22, Juha Manninen via Lazarus wrote: > You should stop writing in this thread now. I agree with Mattias. I perfectly agree with you. But you can't blame me for answering when asked. -Michael From mschnell at lumino.de Wed Aug 16 12:29:53 2017 From: mschnell at lumino.de (Michael Schnell) Date: Wed, 16 Aug 2017 12:29:53 +0200 Subject: [Lazarus] dynamic string proposal In-Reply-To: <20170816115114.06d361db@limapholos.matflo.wg> References: <20170816115114.06d361db@limapholos.matflo.wg> Message-ID: BTW.: This is off topic in the Lazarus list and would be an fpc issue. Moving it in one of the fpc lists would have the additional advantage that I am banned there, anyway, for having answered to similar questions. -Michael From mailinglists at geldenhuys.co.uk Wed Aug 16 13:02:33 2017 From: mailinglists at geldenhuys.co.uk (Graeme Geldenhuys) Date: Wed, 16 Aug 2017 12:02:33 +0100 Subject: [Lazarus] String vs WideString In-Reply-To: References: <20170812223247.73330e02@limapholos.matflo.wg> <20170812224956.4e624b23@limapholos.matflo.wg> <1ivuocdrq736eamemh6mp6h9old5omrssn@4ax.com> <38b0193a-eb86-4d6a-6292-f2203daff126@mccallumwhyman.com> <20170814154654.52d5d1d4@limapholos.matflo.wg> Message-ID: <3fbc4159-8b53-3aa6-3f89-2ae6d0eadcab@geldenhuys.co.uk> On 2017-08-16 11:05, Juha Manninen via Lazarus wrote: > Unfortunately many other programmers had the same wrong idea or they > were just lazy. The result anyway is a lot of broken UTF-16 code out > there. Yeah, I see that even in commercial products and projects. It's very sad to see. Hence I always promote UTF-8, and you can't get it wrong as easily as UTF-16. No endianess to worry about, no surrogate pairs and UTF-8 is ready for streaming (network or disk) out of the box. 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 From nc-gaertnma at netcologne.de Wed Aug 16 13:17:27 2017 From: nc-gaertnma at netcologne.de (Mattias Gaertner) Date: Wed, 16 Aug 2017 13:17:27 +0200 Subject: [Lazarus] dynamic string proposal In-Reply-To: <5fb059ce-6d78-14e2-614a-e30ec476dd28@lumino.de> References: <20170816115114.06d361db@limapholos.matflo.wg> <5fb059ce-6d78-14e2-614a-e30ec476dd28@lumino.de> Message-ID: <20170816131727.49973c7d@limapholos.matflo.wg> On Wed, 16 Aug 2017 12:24:55 +0200 Michael Schnell via Lazarus wrote: > On 16.08.2017 11:51, Mattias Gaertner via Lazarus wrote: > > Every Delphi/FPC type has a bunch of operators. Strings support :=, =, > > <>, >=, <= and [] for read and write. > > When you propose a new string type "dynamicstring" you have to define these operators. >[...] > For "new" encoding brandings, such as CP_Byte, CP_Word, CP_DWord, > CP_QWord, the working of the operators is obvious. There are no such codepages. You are confusing people if you name your encodings like this. > It somebody tries to > compare a printable Text string with a string of binary elements, maybe > the behavior is undefined. Your "dynamicstring" supports char, widechar, byte, word, dword, qword. Why not shortint or smallint? Why not boolean, single and variant? What is the intention of your proposal? Mattias From mschnell at lumino.de Wed Aug 16 13:47:26 2017 From: mschnell at lumino.de (Michael Schnell) Date: Wed, 16 Aug 2017 13:47:26 +0200 Subject: [Lazarus] dynamic string proposal In-Reply-To: <20170816131727.49973c7d@limapholos.matflo.wg> References: <20170816115114.06d361db@limapholos.matflo.wg> <5fb059ce-6d78-14e2-614a-e30ec476dd28@lumino.de> <20170816131727.49973c7d@limapholos.matflo.wg> Message-ID: <6b1b26df-7ff6-067d-7b5a-c8be14b7acad@lumino.de> On 16.08.2017 13:17, Mattias Gaertner via Lazarus wrote: > You are confusing people if you name your encodings like this. There also is no "official" Code pages named "Default" or "None", the naming "CP_DEFAULT" and "CP_NONE" has just been invented by Emparcadero. So I did the same and just brainlessly extended the existing "CP..." naming scheme. > Your "dynamicstring" supports char, widechar, byte, word, dword, qword. > Why not shortint or smallint? > Why not boolean, single and variant? As pointed out this is just a draft of a proposal, prone to enhancement and improvement. > What is the intention of your proposal? That is given in the instructional paragraph "The problem": "The most obvious candidate for pain on that behalf is “TStrings”. Only a fully dynamically encoded version of TStrings and friends would allow for a solution for many string encoding related problems, as the user can't modify the string encoding brand TStrings uses and hence will face the described problems when he uses TStrings with all but one of the String encoding brandings he can choose from. Enhancing the count of available encoding brandings is just a logical consequence of a less problem prone and more versatile (not implicitly restricted to printable text) overall string handling. -Michael (It's rather frustrating to discuss that obviously never will happen :-() From aaa5500 at ya.ru Wed Aug 16 14:22:20 2017 From: aaa5500 at ya.ru (Alexey) Date: Wed, 16 Aug 2017 15:22:20 +0300 Subject: [Lazarus] dynamic string proposal In-Reply-To: <20170816115114.06d361db@limapholos.matflo.wg> References: <20170816115114.06d361db@limapholos.matflo.wg> Message-ID: On 16.08.2017 12:51, Mattias Gaertner via Lazarus wrote: > When you propose a new string type "dynamicstring" you have to define these operators. BTW, it will be good to have "Cstring" (or another name, not "dynamicstring") : - [] operator is 0-based like Python/C - s[i] is DWORD per char (for all Unicode chars from 0 to MaxDWORD codes) PChar(s)/PWChar(s) wont work for it? so it is not ok idea? But this type can be compressed inside, eg in utf8. S[i] is DWORD outside. It is like some class. -- Regards, Alexey From lazarus at mfriebe.de Wed Aug 16 14:30:26 2017 From: lazarus at mfriebe.de (Martin Frb) Date: Wed, 16 Aug 2017 13:30:26 +0100 Subject: [Lazarus] dynamic string proposal In-Reply-To: <20170816115114.06d361db@limapholos.matflo.wg> References: <20170816115114.06d361db@limapholos.matflo.wg> Message-ID: <596475ad-3d21-e62d-8797-ea68e5739bfb@mfriebe.de> On 16/08/2017 10:51, Mattias Gaertner via Lazarus wrote: >> Of course an appropriate "char" type for each string encoding brand >> could to be provided, hence a "CP_QWord Char" as an alias or a QWord. > There is no QWord codepage. That would be confusing. > And that would still not be "char", but "codepoint" A char can be composed of several combining code points (each of them afaik, in the 32 bit range). So a char can have 96 or more bits. (And not all of them have a combined form). From aaa5500 at ya.ru Wed Aug 16 14:37:31 2017 From: aaa5500 at ya.ru (Alexey) Date: Wed, 16 Aug 2017 15:37:31 +0300 Subject: [Lazarus] dynamic string proposal In-Reply-To: <596475ad-3d21-e62d-8797-ea68e5739bfb@mfriebe.de> References: <20170816115114.06d361db@limapholos.matflo.wg> <596475ad-3d21-e62d-8797-ea68e5739bfb@mfriebe.de> Message-ID: On 16.08.2017 15:30, Martin Frb via Lazarus wrote: > > A char can be composed of several combining code points (each of them > afaik, in the 32 bit range). > So a char can have 96 or more bits. (And not all of them have a > combined form). See my prev post: i see that each S[i] good to be like QWord (sizeof(one char)= sizeof(Qword)). It can be TextChar. And type can be TextString. internally it can be compressed to utf8. TextString is good if i want to parse text by "chars". If "char" needs more bytes- lets take more (internally it is same utf8) -- Regards, Alexey From nc-gaertnma at netcologne.de Wed Aug 16 14:43:22 2017 From: nc-gaertnma at netcologne.de (Mattias Gaertner) Date: Wed, 16 Aug 2017 14:43:22 +0200 Subject: [Lazarus] dynamic string proposal In-Reply-To: <6b1b26df-7ff6-067d-7b5a-c8be14b7acad@lumino.de> References: <20170816115114.06d361db@limapholos.matflo.wg> <5fb059ce-6d78-14e2-614a-e30ec476dd28@lumino.de> <20170816131727.49973c7d@limapholos.matflo.wg> <6b1b26df-7ff6-067d-7b5a-c8be14b7acad@lumino.de> Message-ID: <20170816144322.31d2b500@limapholos.matflo.wg> On Wed, 16 Aug 2017 13:47:26 +0200 Michael Schnell via Lazarus wrote: > On 16.08.2017 13:17, Mattias Gaertner via Lazarus wrote: > > You are confusing people if you name your encodings like this. > There also is no "official" Code pages named "Default" or "None", the > naming "CP_DEFAULT" and "CP_NONE" has just been invented by Emparcadero. It is not about "official". A codepage describes a character set. What has your CP_QWORD to do with any character set? >[...] > > What is the intention of your proposal? > > That is given in the instructional paragraph "The problem": > "The most obvious candidate for pain on that behalf is “TStrings”. I read it, but I must admit, I don't understand it. For some unknown reason you want to store different encodings in a TStrings and fear the "time-consuming" and loss-prone auto conversions. And then it sounds as if this is a common problem ("much more urgent"). >[...] > Enhancing the count of available encoding brandings is just a logical > consequence of a less problem prone and more versatile (not implicitly > restricted to printable text) overall string handling. Who wants to have more encodings? AFAIK everyone wants less, preferably only one. > -Michael (It's rather frustrating to discuss that obviously never will > happen :-() Not if complicated things get more complicated. Mattias From mschnell at lumino.de Wed Aug 16 14:48:10 2017 From: mschnell at lumino.de (Michael Schnell) Date: Wed, 16 Aug 2017 14:48:10 +0200 Subject: [Lazarus] dynamic string proposal In-Reply-To: <596475ad-3d21-e62d-8797-ea68e5739bfb@mfriebe.de> References: <20170816115114.06d361db@limapholos.matflo.wg> <596475ad-3d21-e62d-8797-ea68e5739bfb@mfriebe.de> Message-ID: <8fe769cd-e23c-7d8f-2c79-fe1134498769@lumino.de> On 16.08.2017 14:30, Martin Frb via Lazarus wrote: > > And that would still not be "char", but "codepoint" > > A char can be composed of several combining code points (each of them > afaik, in the 32 bit range). > So a char can have 96 or more bits. (And not all of them have a > combined form). Unfortunately in Delphi and FPC the appropriate work-alike existing type is called Char (with certain extensions). It would cause major problems to drop that name for something else, even if that would be appropriate. -Michael From nc-gaertnma at netcologne.de Wed Aug 16 14:51:42 2017 From: nc-gaertnma at netcologne.de (Mattias Gaertner) Date: Wed, 16 Aug 2017 14:51:42 +0200 Subject: [Lazarus] dynamic string proposal In-Reply-To: References: <20170816115114.06d361db@limapholos.matflo.wg> Message-ID: <20170816145142.5aa739b8@limapholos.matflo.wg> On Wed, 16 Aug 2017 15:22:20 +0300 Alexey via Lazarus wrote: > On 16.08.2017 12:51, Mattias Gaertner via Lazarus wrote: > > When you propose a new string type "dynamicstring" you have to define these operators. > > BTW, it will be good to have "Cstring" (or another name, not > "dynamicstring") : > > - [] operator is 0-based like Python/C > > - s[i] is DWORD per char (for all Unicode chars from 0 to MaxDWORD codes) > > PChar(s)/PWChar(s) wont work for it? so it is not ok idea? But this type > can be compressed inside, eg in utf8. S[i] is DWORD outside. It is like > some class. This sounds, as if you want an UTF-32 string type. Michael's proposal is a multi encoded string type, storing Ansi, UTF-8, UTF-16 and UTF-32. Mattias From mschnell at lumino.de Wed Aug 16 14:53:07 2017 From: mschnell at lumino.de (Michael Schnell) Date: Wed, 16 Aug 2017 14:53:07 +0200 Subject: [Lazarus] dynamic string proposal In-Reply-To: References: <20170816115114.06d361db@limapholos.matflo.wg> Message-ID: On 16.08.2017 14:22, Alexey via Lazarus wrote: > BTW, it will be good to have "Cstring" (or another name, not > "dynamicstring") : ... > You are missing the point the paper is supposed to be about: enhancing the versatility of the library functions such as those using TStrings. Not just creating another type of strings, which is nothing but a prerequisite for the main purpose. -Michael From jmlandmesser at gmx.de Wed Aug 16 15:00:24 2017 From: jmlandmesser at gmx.de (Landmesser John) Date: Wed, 16 Aug 2017 15:00:24 +0200 Subject: [Lazarus] GlobalMemoryStatus is Windows only, how to get installed RAM on Linux ? Message-ID: googled in vain ... ... and "TsmBios" ( -> Win/Linux https://github.com/RRUZ/tsmbios ) won't compile :-( So how to get Information about installed RAM on Linux for example? Ok, i could grep "hwinfo" or such in a terminal but thats not what i'm looking for. Tipps are welcome From michael at freepascal.org Wed Aug 16 15:09:29 2017 From: michael at freepascal.org (Michael Van Canneyt) Date: Wed, 16 Aug 2017 15:09:29 +0200 (CEST) Subject: [Lazarus] GlobalMemoryStatus is Windows only, how to get installed RAM on Linux ? In-Reply-To: References: Message-ID: On Wed, 16 Aug 2017, Landmesser John via Lazarus wrote: > googled in vain ... > > ... and "TsmBios" ( -> Win/Linux https://github.com/RRUZ/tsmbios ) won't > compile :-( > > > So how to get Information about installed RAM on Linux for example? > > Ok, i could grep "hwinfo" or such in a terminal but thats not what i'm > looking for. Your best options is most likely to read /proc/meminfo and parse the result. It contains a wealth of information. Michael. From mschnell at lumino.de Wed Aug 16 15:14:02 2017 From: mschnell at lumino.de (Michael Schnell) Date: Wed, 16 Aug 2017 15:14:02 +0200 Subject: [Lazarus] dynamic string proposal In-Reply-To: <20170816144322.31d2b500@limapholos.matflo.wg> References: <20170816115114.06d361db@limapholos.matflo.wg> <5fb059ce-6d78-14e2-614a-e30ec476dd28@lumino.de> <20170816131727.49973c7d@limapholos.matflo.wg> <6b1b26df-7ff6-067d-7b5a-c8be14b7acad@lumino.de> <20170816144322.31d2b500@limapholos.matflo.wg> Message-ID: On 16.08.2017 14:43, Mattias Gaertner via Lazarus wrote: > Not if complicated things get more complicated. Please leave out the additional encoding brands suggested just as an afterthought in the paper. These are not the purpose at all but ()if the other stuff would be in place) just com as a natural enhancement. -Michael From mschnell at lumino.de Wed Aug 16 15:23:18 2017 From: mschnell at lumino.de (Michael Schnell) Date: Wed, 16 Aug 2017 15:23:18 +0200 Subject: [Lazarus] dynamic string proposal In-Reply-To: <20170816144322.31d2b500@limapholos.matflo.wg> References: <20170816115114.06d361db@limapholos.matflo.wg> <5fb059ce-6d78-14e2-614a-e30ec476dd28@lumino.de> <20170816131727.49973c7d@limapholos.matflo.wg> <6b1b26df-7ff6-067d-7b5a-c8be14b7acad@lumino.de> <20170816144322.31d2b500@limapholos.matflo.wg> Message-ID: On 16.08.2017 14:43, Mattias Gaertner via Lazarus wrote: > For some unknown > reason you want to store different encodings in a TStrings and fear > the "time-consuming" and loss-prone auto conversions. It's obvious that a user using a different encoding brand in a string var than that suggested by TStrings (UTF-8 in fpc, UTF-16 in Delphi) implicitly triggers auto-conversion when handling the string. This has several consequences. It might be a really good idea when e.g. doing some code that in a loop needs certain operation that might be very fast with UTF-16 but TStringList would store the data in a more compact way. It might be time consuming when the conversion is done without being necessary. It might be error pone when the user stores some random stuff in the string that is not able to be handled by the conversion forth and back. In any case all this happens without the user being aware of, which might cause frustration. -Michael From juha.manninen62 at gmail.com Wed Aug 16 15:25:34 2017 From: juha.manninen62 at gmail.com (Juha Manninen) Date: Wed, 16 Aug 2017 16:25:34 +0300 Subject: [Lazarus] dynamic string proposal In-Reply-To: References: <20170816115114.06d361db@limapholos.matflo.wg> <596475ad-3d21-e62d-8797-ea68e5739bfb@mfriebe.de> Message-ID: On Wed, Aug 16, 2017 at 3:37 PM, Alexey via Lazarus wrote: > See my prev post: i see that each S[i] good to be like QWord (sizeof(one > char)= sizeof(Qword)). It can be TextChar. And type can be TextString. > internally it can be compressed to utf8. TextString is good if i want to > parse text by "chars". If "char" needs more bytes- lets take more > (internally it is same utf8) No Alexey, you are now explaining codepoints. Codeunits and codepoints are the easy part in any case. Could you please define character. Juha From juha.manninen62 at gmail.com Wed Aug 16 15:33:28 2017 From: juha.manninen62 at gmail.com (Juha Manninen) Date: Wed, 16 Aug 2017 16:33:28 +0300 Subject: [Lazarus] dynamic string proposal In-Reply-To: <6b1b26df-7ff6-067d-7b5a-c8be14b7acad@lumino.de> References: <20170816115114.06d361db@limapholos.matflo.wg> <5fb059ce-6d78-14e2-614a-e30ec476dd28@lumino.de> <20170816131727.49973c7d@limapholos.matflo.wg> <6b1b26df-7ff6-067d-7b5a-c8be14b7acad@lumino.de> Message-ID: On Wed, Aug 16, 2017 at 2:47 PM, Michael Schnell via Lazarus wrote: > -Michael (It's rather frustrating to discuss that obviously never will > happen :-() Why don't you implement such a system. This is all FOSS, free and open source. You are writing about encodings etc. which are part of codepoints, but you call them "characters". Why? Is it possible you don't know Unicode beyond codepoints? Do you have plans to tackle also the complex issues of Unicode? If not, then your efforts are useless because codeunits and codepoints are easy in any case. You use energy for a problem that does not exist. Juha From mailinglists at geldenhuys.co.uk Wed Aug 16 15:38:25 2017 From: mailinglists at geldenhuys.co.uk (Graeme Geldenhuys) Date: Wed, 16 Aug 2017 14:38:25 +0100 Subject: [Lazarus] GlobalMemoryStatus is Windows only, how to get installed RAM on Linux ? In-Reply-To: References: Message-ID: <1f9edb9e-5feb-876f-d23c-d99cf6bd3e4a@geldenhuys.co.uk> On 2017-08-16 14:09, Michael Van Canneyt via Lazarus wrote: > Your best options is most likely to read /proc/meminfo and parse the result. > It contains a wealth of information. Just a side note: /proc/meminfo is specific to Linux, and doesn't apply to other Unix-like operating systems like Solaris, FreeBSD etc. For example, under FreeBSD you can execute the following command and read the results back. $ /sbin/sysctl hw.physmem hw.physmem: 34,272,751,616 ..and similar for other hardware under FreeBSD: $ /sbin/sysctl hw.model hw.model: Intel(R) Core(TM) i7-3770K CPU @ 3.50GHz Also worthy noting that the sysctl command can be executed without root access, even though it lives in the 'sbin' directory. This is super handy. Landmesser John, if you look in the OnGuard project in the source/onguard.pas unit, there is code for Windows, Linux and FreeBSD (latter is still limited info) that extracts such information. You are welcome to copy some of that code as you need it. The OnGuard Git repository can be found in the link below, and the web interface also has a "download zip" option. https://github.com/graemeg/onguard 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 From mschnell at lumino.de Wed Aug 16 15:49:03 2017 From: mschnell at lumino.de (Michael Schnell) Date: Wed, 16 Aug 2017 15:49:03 +0200 Subject: [Lazarus] dynamic string proposal In-Reply-To: References: <20170816115114.06d361db@limapholos.matflo.wg> <5fb059ce-6d78-14e2-614a-e30ec476dd28@lumino.de> <20170816131727.49973c7d@limapholos.matflo.wg> <6b1b26df-7ff6-067d-7b5a-c8be14b7acad@lumino.de> Message-ID: On 16.08.2017 15:33, Juha Manninen via Lazarus wrote: > Why don't you implement such a system. This is all FOSS, free and open > source. I would never dare to try to edit the compiler :-[ > You are writing about encodings etc. which are part of codepoints, but > you call them "characters". Why? Because the type for this stuff used in Delphi and and FPC is called "char". > Is it possible you don't know Unicode beyond codepoints? In fact I did not explicitly talk about Unicode at all. the paper says it: "In this article, a "String" is thought of as a reference counted ordered array of a number of "Things" (aka elements). (I feel that this is what the name String suggests.)" ..."If the elements of the strings are printable characters or partial codes of UTF. OK, this is nice (provided the conversion functions are in place) and makes doing programs handling conventional problems very easy" ... > Do you have plans to tackle also the complex issues of Unicode? Not at all. > If not, then your efforts are useless because codeunits and codepoints > are easy in any case. I know. The intention was to handle a completely different problem from that you suggest here. > You use energy for a problem that does not > exist. I wrote the paper because I once was requested to do so in the fpc forum. -Michael From md at delfire.net Wed Aug 16 16:13:29 2017 From: md at delfire.net (Marcos Douglas B. Santos) Date: Wed, 16 Aug 2017 11:13:29 -0300 Subject: [Lazarus] String vs WideString In-Reply-To: References: <20170812223247.73330e02@limapholos.matflo.wg> <20170812224956.4e624b23@limapholos.matflo.wg> <1ivuocdrq736eamemh6mp6h9old5omrssn@4ax.com> <38b0193a-eb86-4d6a-6292-f2203daff126@mccallumwhyman.com> Message-ID: On Wed, Aug 16, 2017 at 6:12 AM, Juha Manninen via Lazarus wrote: > On Mon, Aug 14, 2017 at 4:11 PM, Marcos Douglas B. Santos via Lazarus > wrote: >> Unicode everywhere and you using AnsiString and doing everything... >> Now I'm confused. > > Yes, please read: > http://wiki.freepascal.org/Unicode_Support_in_Lazarus > I have advertised it so much that some people are already irritated, > but maybe you missed it so far. Thanks. I know about this page... unfortunately looks like it is not enough, since many others still complain. >> This is a ugly trick... but I understood what you mean. > > This was about the explicit temporary UnicodeString variable for > WinAPI call parameters. > No, it is not ugly, the code remains 100% compatible with Delphi. > Please remember also that direct WinAPI call are not needed in > cross-platform code. This thread is not only about WinAPI. I have this problem because I need to use a Windows 3rd Lib, which uses WideString. Best regards, Marcos Douglas From juha.manninen62 at gmail.com Wed Aug 16 16:37:07 2017 From: juha.manninen62 at gmail.com (Juha Manninen) Date: Wed, 16 Aug 2017 17:37:07 +0300 Subject: [Lazarus] String vs WideString In-Reply-To: References: <20170812223247.73330e02@limapholos.matflo.wg> <20170812224956.4e624b23@limapholos.matflo.wg> <1ivuocdrq736eamemh6mp6h9old5omrssn@4ax.com> <38b0193a-eb86-4d6a-6292-f2203daff126@mccallumwhyman.com> Message-ID: On Wed, Aug 16, 2017 at 5:13 PM, Marcos Douglas B. Santos via Lazarus wrote: > Thanks. I know about this page... unfortunately looks like it is not > enough, since many others still complain. What is missing? I can try to improve it. > This thread is not only about WinAPI. I have this problem because I > need to use a Windows 3rd Lib, which uses WideString. Then just use WideString or UnicodeString where needed. It is not a problem. Note, WideString is for OLE programming. Most often you should use UnicodeString. Their memory management differs. Juha From lazarus at mfriebe.de Wed Aug 16 16:36:15 2017 From: lazarus at mfriebe.de (Martin Frb) Date: Wed, 16 Aug 2017 15:36:15 +0100 Subject: [Lazarus] dynamic string proposal In-Reply-To: References: <20170816115114.06d361db@limapholos.matflo.wg> <596475ad-3d21-e62d-8797-ea68e5739bfb@mfriebe.de> Message-ID: <9e1670b3-1820-684a-0201-11f103c6dcc9@mfriebe.de> On 16/08/2017 13:37, Alexey via Lazarus wrote: > On 16.08.2017 15:30, Martin Frb via Lazarus wrote: >> >> A char can be composed of several combining code points (each of them >> afaik, in the 32 bit range). >> So a char can have 96 or more bits. (And not all of them have a >> combined form). > > See my prev post: i see that each S[i] good to be like QWord > (sizeof(one char)= sizeof(Qword)). It can be TextChar. And type can be > TextString. internally it can be compressed to utf8. TextString is > good if i want to parse text by "chars". If "char" needs more bytes- > lets take more (internally it is same utf8) > Have a look at https://www.reddit.com/r/Unicode/comments/4yie0a/tallest_longest_unicode_character/ There is ONE character, that comprises more than 200 codepoints. Only way to store such a char is in a type of dynamic size (aka string) Well I couldn't find an official doc what makes the boundaries of a char. But as far as I can see: if ä is one character, and it can be encoded as "none combining codepoint" + "combining codepoint", then a character is any sequence of one "none combining codepoint" + zero or more "combining codepoints" (AFAIK Arabic scripts has chars, that have several "combining codepoints", so this is happening in actual languages. The example as far as I checked fulfils this definition. From lazarus at mfriebe.de Wed Aug 16 16:39:21 2017 From: lazarus at mfriebe.de (Martin Frb) Date: Wed, 16 Aug 2017 15:39:21 +0100 Subject: [Lazarus] dynamic string proposal In-Reply-To: <8fe769cd-e23c-7d8f-2c79-fe1134498769@lumino.de> References: <20170816115114.06d361db@limapholos.matflo.wg> <596475ad-3d21-e62d-8797-ea68e5739bfb@mfriebe.de> <8fe769cd-e23c-7d8f-2c79-fe1134498769@lumino.de> Message-ID: <6fc471ee-50ad-ff6a-887a-530e9968f065@mfriebe.de> On 16/08/2017 13:48, Michael Schnell wrote: > On 16.08.2017 14:30, Martin Frb via Lazarus wrote: >> >> And that would still not be "char", but "codepoint" >> >> A char can be composed of several combining code points (each of them >> afaik, in the 32 bit range). >> So a char can have 96 or more bits. (And not all of them have a >> combined form). > Unfortunately in Delphi and FPC the appropriate work-alike existing > type is called Char (with certain extensions). It would cause major > problems to drop that name for something else, even if that would be > appropriate. I agree. "char" actually is a "code unit". But renaming it, would probably be as good as killing the language. and anyone can do type codeunit=char; and use this. From md at delfire.net Wed Aug 16 16:48:43 2017 From: md at delfire.net (Marcos Douglas B. Santos) Date: Wed, 16 Aug 2017 11:48:43 -0300 Subject: [Lazarus] String vs WideString In-Reply-To: References: <20170812223247.73330e02@limapholos.matflo.wg> <20170812224956.4e624b23@limapholos.matflo.wg> <1ivuocdrq736eamemh6mp6h9old5omrssn@4ax.com> <38b0193a-eb86-4d6a-6292-f2203daff126@mccallumwhyman.com> Message-ID: On Wed, Aug 16, 2017 at 11:37 AM, Juha Manninen via Lazarus wrote: > On Wed, Aug 16, 2017 at 5:13 PM, Marcos Douglas B. Santos via Lazarus > wrote: >> Thanks. I know about this page... unfortunately looks like it is not >> enough, since many others still complain. > > What is missing? I can try to improve it. I cannot say from others, but I had this issue (about WideString) for now. >> This thread is not only about WinAPI. I have this problem because I >> need to use a Windows 3rd Lib, which uses WideString. > > Then just use WideString or UnicodeString where needed. It is not a problem. Are you saying that I need to do this? (following the firt example on this thread) === begin === var U: UnicodeString; W: WideString; begin U := IniFile.ReadString('TheLib', 'license', ''); W := U; Lib.SetLicense(W); // ... end; === end === ...and I will not get a "Warning", right? > Note, WideString is for OLE programming. Most often you should use > UnicodeString. Their memory management differs. Ok... thanks... but in my case is a OLE object that I need to use. Best regards, Marcos Douglas From juha.manninen62 at gmail.com Wed Aug 16 17:20:07 2017 From: juha.manninen62 at gmail.com (Juha Manninen) Date: Wed, 16 Aug 2017 18:20:07 +0300 Subject: [Lazarus] dynamic string proposal In-Reply-To: References: <20170816115114.06d361db@limapholos.matflo.wg> <5fb059ce-6d78-14e2-614a-e30ec476dd28@lumino.de> <20170816131727.49973c7d@limapholos.matflo.wg> <6b1b26df-7ff6-067d-7b5a-c8be14b7acad@lumino.de> Message-ID: On Wed, Aug 16, 2017 at 4:49 PM, Michael Schnell via Lazarus wrote: >> You are writing about encodings etc. which are part of codepoints, but >> you call them "characters". Why? > > Because the type for this stuff used in Delphi and and FPC is called "char". No, actually the Pascal type "Char" contains a CodeUnit, not CodePoint. It is the smallest fixed width "atom" of Unicode text. It is still extremely useful in Unicode related programming. The word "character" in Unicode can mean: 1. CodeUnit — Represented by Pascal type "Char". 2. CodePoint — all the arguments about one encoding's supremacy over another deal with CodePoints. Yes, UTF-8, UTF-16, UTF-32 etc. all only encode CodePoints. 3. Abstract Unicode character — like 🍷 'WINE GLASS'. 4. Coded Unicode character — "U" + a unique number, like U+1F377. This is what "character" means in Unicode Standard. 5. User-perceived character — Whatever the end user thinks of as a character. This is language dependent. For instance, ‘ch’ is two letters in English but one letter in Czech and Slovak. Many more complexities are involved here, including decomposed codepoints. 6. Grapheme cluster 7. Glyph — related to fonts. So, number 4. is the official Unicode "character". Otherwise the most useful meanings are 1. "CodeUnit" for programmers and 5. "User-perceived character" for everybody else. Note, CodePoint is NOT a useful meaning for "character". It would only confuse things. Yet most people in these Unicode threads write about "character" like it meant CodePoint. It can only mean that those people are ignorant of the complexity of Unicode. :( > In fact I did not explicitly talk about Unicode at all. the paper says it: > ... Unicode is the standard now. We cannot ignore it, and we don't want to ignore it because it solves so many problems of the earlier solutions. If you create a new string type, you certainly must take Unicode into account. Juha From lazarus at mfriebe.de Wed Aug 16 17:24:13 2017 From: lazarus at mfriebe.de (Martin Frb) Date: Wed, 16 Aug 2017 16:24:13 +0100 Subject: [Lazarus] dynamic string proposal In-Reply-To: References: <20170816115114.06d361db@limapholos.matflo.wg> <5fb059ce-6d78-14e2-614a-e30ec476dd28@lumino.de> <20170816131727.49973c7d@limapholos.matflo.wg> <6b1b26df-7ff6-067d-7b5a-c8be14b7acad@lumino.de> Message-ID: On 16/08/2017 16:20, Juha Manninen via Lazarus wrote: > > The word "character" in Unicode can mean: > > 1. CodeUnit — Represented by Pascal type "Char". Actually no. It can overlap. But a codeunit is NOT a character. For example a codeunit that holds a codepoint of class "combining mark", this is not a character. It is just something that can form a character if combined with other codepoints. > 2. CodePoint Also not a character. Same as above. Some Codepoints happen to also be a character. But some are not. From juha.manninen62 at gmail.com Wed Aug 16 17:38:15 2017 From: juha.manninen62 at gmail.com (Juha Manninen) Date: Wed, 16 Aug 2017 18:38:15 +0300 Subject: [Lazarus] String vs WideString In-Reply-To: References: <20170812223247.73330e02@limapholos.matflo.wg> <20170812224956.4e624b23@limapholos.matflo.wg> <1ivuocdrq736eamemh6mp6h9old5omrssn@4ax.com> <38b0193a-eb86-4d6a-6292-f2203daff126@mccallumwhyman.com> Message-ID: On Wed, Aug 16, 2017 at 5:48 PM, Marcos Douglas B. Santos via Lazarus wrote: > I cannot say from others, but I had this issue (about WideString) for now. The section "Calling Windows API" says: 'Only the "W" versions of Windows API functions should be called. It is like in Delphi except that you must assign strings to/from API calls to UnicodeString variables or typecast with UnicodeString().' Then it also explains the difference between WideString and UnicodeString. I should add a mention about PWideChar parameters. Anyway the idea is to keep the information useful and dense. Earlier it was bloated and intimidating. > Are you saying that I need to do this? > (following the firt example on this thread) No, if the parameter is WideString, not a pointer PWideChar, you can just call it like you did. Suppress the warning as Mattias told if it bothers you. You can also make a helper function so the conversion happens in one place. Yes, for OLE you need WideString. Juha From juha.manninen62 at gmail.com Wed Aug 16 17:55:54 2017 From: juha.manninen62 at gmail.com (Juha Manninen) Date: Wed, 16 Aug 2017 18:55:54 +0300 Subject: [Lazarus] dynamic string proposal In-Reply-To: References: <20170816115114.06d361db@limapholos.matflo.wg> <5fb059ce-6d78-14e2-614a-e30ec476dd28@lumino.de> <20170816131727.49973c7d@limapholos.matflo.wg> <6b1b26df-7ff6-067d-7b5a-c8be14b7acad@lumino.de> Message-ID: On Wed, Aug 16, 2017 at 6:24 PM, Martin Frb via Lazarus wrote: > Actually no. I know CodeUnit and CodePoint are not called "character" officially by the Unicode Standard. They however are called "character" in normal communication. For example in the "String vs WideString" thread most people used "character" as a synonym for CodePoint. For CodeUnit the term is very logical for historical reasons as the type "Char" is a short form of "Character". This is a very important meaning because CodeUnit resolution is so useful also with variable width encodings. For example the following code works perfectly with UTF-8 and UTF-16: function SplitInHalf(Txt, Separator: string; out Half1, Half2: string): Boolean; var i: Integer; begin i := Pos(Separator, Txt); Result := i > 0; if Result then begin Half1 := Copy(Txt, 1, i-1); Half2 := Copy(Txt, i+Length(Separator), Length(Txt)); end; end; although Pos(), Copy() and Length() deal with CodeUnit resolution. I wonder how the new fancy string types would handle it without a performance penalty. Juha From mschnell at lumino.de Wed Aug 16 17:58:21 2017 From: mschnell at lumino.de (Michael Schnell) Date: Wed, 16 Aug 2017 17:58:21 +0200 Subject: [Lazarus] dynamic string proposal In-Reply-To: References: <20170816115114.06d361db@limapholos.matflo.wg> <5fb059ce-6d78-14e2-614a-e30ec476dd28@lumino.de> <20170816131727.49973c7d@limapholos.matflo.wg> <6b1b26df-7ff6-067d-7b5a-c8be14b7acad@lumino.de> Message-ID: <0dc14f78-69cc-5fed-6e1e-d3144aad1cd7@lumino.de> On 16.08.2017 17:20, Juha Manninen via Lazarus wrote: > > Unicode is the standard now. We cannot ignore it, and we don't want to > ignore it because it solves so many problems of the earlier solutions. > If you create a new string type, you certainly must take Unicode into account. It is not "ignored", as it is handled by the conversion functions the functionality of which is not touched. The paper is just about storing the information in the strings (including the "encoding brand" and "bytes per element") fields. So the actual meaning of the stuff that is stored in the strings is beyond the scope of the paper. And supposed to stay as it currently is. -Michael From mschnell at lumino.de Wed Aug 16 18:06:36 2017 From: mschnell at lumino.de (Michael Schnell) Date: Wed, 16 Aug 2017 18:06:36 +0200 Subject: [Lazarus] dynamic string proposal In-Reply-To: References: <20170816115114.06d361db@limapholos.matflo.wg> <5fb059ce-6d78-14e2-614a-e30ec476dd28@lumino.de> <20170816131727.49973c7d@limapholos.matflo.wg> <6b1b26df-7ff6-067d-7b5a-c8be14b7acad@lumino.de> Message-ID: <8fc0a5c0-43d0-6d1b-96ea-05d2daf3862c@lumino.de> On 16.08.2017 17:55, Juha Manninen via Lazarus wrote: > although Pos(), Copy() and Length() deal with CodeUnit resolution. > I wonder how the new fancy string types would handle it without a > performance penalty. This again is not in the scope of the paper, and supposed to stay as it is. S[x], Pos(), and friends work in terms of "bytes per element" bytes. The only difference to the current status is that with the "dynamic" string brand the content of the "bytes per element" field is not predefined by the variable declaration but can change when something is assigned to that (additional) brand of string variables (I feel that this is clearly stated in the paper). Hence for that (additional) brand of string variables the compiler needs to generate code to read this field when implementing the built-in functions. -Michael From nc-gaertnma at netcologne.de Wed Aug 16 18:24:57 2017 From: nc-gaertnma at netcologne.de (Mattias Gaertner) Date: Wed, 16 Aug 2017 18:24:57 +0200 Subject: [Lazarus] dynamic string proposal In-Reply-To: <8fc0a5c0-43d0-6d1b-96ea-05d2daf3862c@lumino.de> References: <20170816115114.06d361db@limapholos.matflo.wg> <5fb059ce-6d78-14e2-614a-e30ec476dd28@lumino.de> <20170816131727.49973c7d@limapholos.matflo.wg> <6b1b26df-7ff6-067d-7b5a-c8be14b7acad@lumino.de> <8fc0a5c0-43d0-6d1b-96ea-05d2daf3862c@lumino.de> Message-ID: <20170816182457.6275d5a6@limapholos.matflo.wg> On Wed, 16 Aug 2017 18:06:36 +0200 Michael Schnell via Lazarus wrote: >[...] > The only difference to the current status is that with the "dynamic" > string brand the content of the "bytes per element" field is not > predefined by the variable declaration but can change when something is > assigned to that (additional) brand of string variables (I feel that > this is clearly stated in the paper). Hence for that (additional) brand > of string variables the compiler needs to generate code to read this > field when implementing the built-in functions. This "dynamicstring" sounds like Rawbytestring times two. Any function accessing the inner chars of a "dynamicstring" has to handle Rawbytestring codepages and unicodestring and array of byte/word/dword. If this is the price for avoiding some conversions, many programmers will become unhappy. Michael, please tell me your proposal has some serious advantages. I don't see them. Mattias From lazarus at mfriebe.de Wed Aug 16 18:53:16 2017 From: lazarus at mfriebe.de (Martin Frb) Date: Wed, 16 Aug 2017 17:53:16 +0100 Subject: [Lazarus] dynamic string proposal In-Reply-To: References: <20170816115114.06d361db@limapholos.matflo.wg> <5fb059ce-6d78-14e2-614a-e30ec476dd28@lumino.de> <20170816131727.49973c7d@limapholos.matflo.wg> <6b1b26df-7ff6-067d-7b5a-c8be14b7acad@lumino.de> Message-ID: On 16/08/2017 16:55, Juha Manninen via Lazarus wrote: > On Wed, Aug 16, 2017 at 6:24 PM, Martin Frb via Lazarus > wrote: >> Actually no. > I know CodeUnit and CodePoint are not called "character" officially by > the Unicode Standard. > They however are called "character" in normal communication. And that is where the problem starts. As long as people do this, even if they know it is incorrect, others will pick it up, and others will learn the wrong concepts. Calling codepoints = char, means that newcomers will think s[x] is a valid way to deal with chars. And that is wrong, even in utf32. > For example in the "String vs WideString" thread most people used > "character" as a synonym for CodePoint. Lots of people used the word character as if they where the same as codeunit. But the questions is did they use it as synonym? I.e did they know they were substituting with the wrong word? If so, why would they intentionally use misleading terms? > For CodeUnit the term is very logical for historical reasons as the > type "Char" is a short form of "Character". That is why today it is a misnomer. So using "char" (the type) as reference to "codepoint" is something we have to do, because today the type "char" is for codepoints. That is different from the English word "char" and that can cause a huge confusion. The English word "character" however is unambitious. It is not the name of a type. So it refers to character only, not to codepoint. From pascaldragon at googlemail.com Wed Aug 16 19:29:17 2017 From: pascaldragon at googlemail.com (Sven Barth) Date: Wed, 16 Aug 2017 19:29:17 +0200 Subject: [Lazarus] String vs WideString In-Reply-To: References: <20170812223247.73330e02@limapholos.matflo.wg> <20170812224956.4e624b23@limapholos.matflo.wg> <1ivuocdrq736eamemh6mp6h9old5omrssn@4ax.com> <38b0193a-eb86-4d6a-6292-f2203daff126@mccallumwhyman.com> <20170814154654.52d5d1d4@limapholos.matflo.wg> Message-ID: On 15.08.2017 10:34, Tony Whyman via Lazarus wrote: > On 14/08/17 17:47, Sven Barth via Lazarus wrote: >> The main problem of such a dynamic type would be the inability to do >> fast indexing as the compiler would need to insert runtime checks for >> the size of a character. I had already thought the same, but then had >> to discard the idea due to this. > > Is this really a big problem? It is not as if it would be necessary to > do a table lookup everytime you index a string as the indexing method > could be an attribute of the string and updated with the character > encoding attribute. Is it really that complicated for the compiler to > generate code that jumps to an indexing method depending upon a data > attribute? In a tight loop where one accesss the string character by character (take Pos() for example) this will lead to a significant slowdown as the compiler (without optimizations) will have to insert a call to the lookup function for each access. While I generally don't consider performance degradation as a backwards compatibility issue I do in this case, due to the significant decrease in performance. Take this evaluation example: === code begin === program tperf; {$mode objfpc}{$H+} uses SysUtils; function lookup(const aStr: String; aIndex: SizeInt): Char; begin Result := aStr[aIndex]; end; var str: String; starttime, endtime: TDateTime; i, j: LongInt; begin SetLength(str, 10000); starttime := Now; for i := 0 to 10000 do for j := 1 to Length(str) do if str[j] <> '' then ; endtime := Now; Writeln('Direct: ', FormatDateTime('hh:nn:ss.zzz', endtime - starttime)); starttime := Now; for i := 0 to 10000 do for j := 1 to Length(str) do if lookup(str, j) <> '' then ; endtime := Now; Writeln('Lookup: ', FormatDateTime('hh:nn:ss.zzz', endtime - starttime)); end. === code end === === output begin === Direct: 00:00:01.766 Lookup: 00:00:02.061 === output end === While this example is of course artificial it nevertheless shows the slow down. > Is your problem really more about the result type as, depending on the > character width, the result could be an AnsiChar or WideChar or a UTF8 > character for which I don't believe there is a defined char type (other > than an arguable mis-use of UCS4Char)? That is indeed also a problem. I might not have had that one in mind with my mail above, but I did back then when I had brainstormed this. > I can accept that a clear up of this area would also have to extend to > the char types as well - but I would also argue that that is well > overdue. On a quick count, I found 7 different char types in the system > unit. And most important of all: any solution that is developed *MUST* be backwards compatible, so that means that in the least that type aliases would remain anyway. Regards, Sven From pascaldragon at googlemail.com Wed Aug 16 19:35:23 2017 From: pascaldragon at googlemail.com (Sven Barth) Date: Wed, 16 Aug 2017 19:35:23 +0200 Subject: [Lazarus] String vs WideString In-Reply-To: <762d5869-d011-a91e-6571-317d4ad01c45@geldenhuys.co.uk> References: <1ivuocdrq736eamemh6mp6h9old5omrssn@4ax.com> <38b0193a-eb86-4d6a-6292-f2203daff126@mccallumwhyman.com> <20170814154654.52d5d1d4@limapholos.matflo.wg> <20170815111313.0d368eaf@limapholos.matflo.wg> <49d88133-d578-d80c-c080-58b635602054@lumino.de> <762d5869-d011-a91e-6571-317d4ad01c45@geldenhuys.co.uk> Message-ID: On 16.08.2017 11:08, Graeme Geldenhuys via Lazarus wrote: > On 2017-08-16 09:43, Michael Schnell via Lazarus wrote: >> IMHO, any implementation of TStrings that forces a conversion (just >> because the class uses TStrings and not due to a logical demand), is a >> contradiction to providing code aware strings at all. > > But in FPC 3.x (using modern compiler modes - not TP or Mac) String = > UnicodeString. So it makes sense that TStrings should use UnicodeString > internally to store its data. The Unicode standard is also the only > standard that can support any language. So all Windows code-pages can be > supported with the single UnicodeString type. You are wrong. The string types in 3.0.x and 3.1 are like this: TP, Iso, ExtPas, MacPas, FPC, ObjFPC (or below modes with $H-): String = ShortString Delphi (or other modes with $H+): String = AnsiString (or more precisely String(CP_ACP), meaning the system codepage) Delphi_Unicode (or other modes with $H+ and $modeswitch unicodestring): String = UnicodeString Regards, Sven From luca at wetron.es Wed Aug 16 20:26:50 2017 From: luca at wetron.es (Luca Olivetti) Date: Wed, 16 Aug 2017 20:26:50 +0200 Subject: [Lazarus] String vs WideString In-Reply-To: References: <1ivuocdrq736eamemh6mp6h9old5omrssn@4ax.com> <38b0193a-eb86-4d6a-6292-f2203daff126@mccallumwhyman.com> <20170814154654.52d5d1d4@limapholos.matflo.wg> <20170815111313.0d368eaf@limapholos.matflo.wg> <3956bacd-2902-ea33-060b-252de9f97ca5@geldenhuys.co.uk> <66aa5516-1c29-f48e-1337-13abd8413e8d@wetron.es> <624223a6-e1ff-0006-0134-2777ffda4bc8@geldenhuys.co.uk> Message-ID: El 16/08/17 a les 01:17, Graeme Geldenhuys via Lazarus ha escrit: > In hind sight, using TBytes or TMemoryStream and it would have been very > clear that it is a storage container for byte sized data, and no > automatic conversion (by the compiler) would be done to data stored in > such containers. Call me lazy but I don't want to reinvent the wheel and re-implement from scratch the functionality that a plain ansistring provides and TBytes to this day doesn't. I mean, TBytes is just an "array of char". I can't (easily) add a byte to the end, cut a slice of the bytes, find one byte in the array, etc. OK, I can, but I have to program it all by myself while a string does all that and more and probably it's a lot more efficient. Bye -- Luca Olivetti Wetron Automation Technology http://www.wetron.es/ Tel. +34 93 5883004 (Ext.3010) Fax +34 93 5883007 From luca at wetron.es Wed Aug 16 20:28:27 2017 From: luca at wetron.es (Luca Olivetti) Date: Wed, 16 Aug 2017 20:28:27 +0200 Subject: [Lazarus] String vs WideString In-Reply-To: References: <38b0193a-eb86-4d6a-6292-f2203daff126@mccallumwhyman.com> <20170814154654.52d5d1d4@limapholos.matflo.wg> <20170815111313.0d368eaf@limapholos.matflo.wg> <3956bacd-2902-ea33-060b-252de9f97ca5@geldenhuys.co.uk> <66aa5516-1c29-f48e-1337-13abd8413e8d@wetron.es> <624223a6-e1ff-0006-0134-2777ffda4bc8@geldenhuys.co.uk> Message-ID: <89895f14-5a9b-4055-e114-66b88fbdd194@wetron.es> El 16/08/17 a les 20:26, Luca Olivetti via Lazarus ha escrit: > El 16/08/17 a les 01:17, Graeme Geldenhuys via Lazarus ha escrit: > >> In hind sight, using TBytes or TMemoryStream and it would have been >> very clear that it is a storage container for byte sized data, and no >> automatic conversion (by the compiler) would be done to data stored in >> such containers. > > Call me lazy but I don't want to reinvent the wheel and re-implement > from scratch the functionality that a plain ansistring provides and > TBytes to this day doesn't. > I mean, TBytes is just an "array of char". I can't (easily) add a byte > to the end, cut a slice of the bytes, find one byte in the array, etc. > OK, I can, but I have to program it all by myself while a string does > all that and more and probably it's a lot more efficient. Not to mention that its index starts from 0. If I wanted to program in C I would be programming in C, not pascal ;-) Bye -- Luca Olivetti Wetron Automation Technology http://www.wetron.es/ Tel. +34 93 5883004 (Ext.3010) Fax +34 93 5883007 From juha.manninen62 at gmail.com Wed Aug 16 21:44:49 2017 From: juha.manninen62 at gmail.com (Juha Manninen) Date: Wed, 16 Aug 2017 22:44:49 +0300 Subject: [Lazarus] dynamic string proposal In-Reply-To: References: <20170816115114.06d361db@limapholos.matflo.wg> <5fb059ce-6d78-14e2-614a-e30ec476dd28@lumino.de> <20170816131727.49973c7d@limapholos.matflo.wg> <6b1b26df-7ff6-067d-7b5a-c8be14b7acad@lumino.de> Message-ID: On Wed, Aug 16, 2017 at 7:53 PM, Martin Frb via Lazarus wrote: >> I know CodeUnit and CodePoint are not called "character" officially by >> the Unicode Standard. >> They however are called "character" in normal communication. > > And that is where the problem starts. > ... Exactly. Discussions where the word "character" is used are very vague and inaccurate. > So using "char" (the type) as reference to "codepoint" is something we have > to do, because today the type "char" is for codepoints. Sorry I didn't understand this one. "Char" (the type) holds a codeunit, not a codepoint. Char is either 1 byte or 2 bytes depending on if it maps to AnsiChar or WideChar, for UTF-8 or UTF-16 respectively. Juha From lazarus at mfriebe.de Wed Aug 16 22:19:10 2017 From: lazarus at mfriebe.de (Martin Frb) Date: Wed, 16 Aug 2017 21:19:10 +0100 Subject: [Lazarus] dynamic string proposal In-Reply-To: References: <20170816115114.06d361db@limapholos.matflo.wg> <5fb059ce-6d78-14e2-614a-e30ec476dd28@lumino.de> <20170816131727.49973c7d@limapholos.matflo.wg> <6b1b26df-7ff6-067d-7b5a-c8be14b7acad@lumino.de> Message-ID: On 16/08/2017 20:44, Juha Manninen via Lazarus wrote: > >> So using "char" (the type) as reference to "codepoint" is something we have >> to do, because today the type "char" is for codepoints. > Sorry I didn't understand this one. > "Char" (the type) holds a codeunit, not a codepoint. Char is either 1 Right yes. Genuine mistake with all the confusion.... From pascaldragon at googlemail.com Wed Aug 16 22:40:01 2017 From: pascaldragon at googlemail.com (Sven Barth) Date: Wed, 16 Aug 2017 22:40:01 +0200 Subject: [Lazarus] String vs WideString In-Reply-To: References: <38b0193a-eb86-4d6a-6292-f2203daff126@mccallumwhyman.com> <20170814154654.52d5d1d4@limapholos.matflo.wg> <20170815111313.0d368eaf@limapholos.matflo.wg> <3956bacd-2902-ea33-060b-252de9f97ca5@geldenhuys.co.uk> <66aa5516-1c29-f48e-1337-13abd8413e8d@wetron.es> <624223a6-e1ff-0006-0134-2777ffda4bc8@geldenhuys.co.uk> Message-ID: On 16.08.2017 20:26, Luca Olivetti via Lazarus wrote: > El 16/08/17 a les 01:17, Graeme Geldenhuys via Lazarus ha escrit: > >> In hind sight, using TBytes or TMemoryStream and it would have been >> very clear that it is a storage container for byte sized data, and no >> automatic conversion (by the compiler) would be done to data stored in >> such containers. > > Call me lazy but I don't want to reinvent the wheel and re-implement > from scratch the functionality that a plain ansistring provides and > TBytes to this day doesn't. > I mean, TBytes is just an "array of char". I can't (easily) add a byte > to the end, cut a slice of the bytes, find one byte in the array, etc. > OK, I can, but I have to program it all by myself while a string does > all that and more and probably it's a lot more efficient. Trunk supports Insert() and Delete() on dynamic arrays, Concat() and + are on the near term ToDo list. Regards, Sven From luca at wetron.es Thu Aug 17 00:46:33 2017 From: luca at wetron.es (Luca Olivetti) Date: Thu, 17 Aug 2017 00:46:33 +0200 Subject: [Lazarus] String vs WideString In-Reply-To: References: <38b0193a-eb86-4d6a-6292-f2203daff126@mccallumwhyman.com> <20170814154654.52d5d1d4@limapholos.matflo.wg> <20170815111313.0d368eaf@limapholos.matflo.wg> <3956bacd-2902-ea33-060b-252de9f97ca5@geldenhuys.co.uk> <66aa5516-1c29-f48e-1337-13abd8413e8d@wetron.es> <624223a6-e1ff-0006-0134-2777ffda4bc8@geldenhuys.co.uk> Message-ID: <4bd55f90-8649-94cf-aa97-e4df0786a197@wetron.es> El 16/08/17 a les 22:40, Sven Barth via Lazarus ha escrit: > On 16.08.2017 20:26, Luca Olivetti via Lazarus wrote: >> El 16/08/17 a les 01:17, Graeme Geldenhuys via Lazarus ha escrit: >> >>> In hind sight, using TBytes or TMemoryStream and it would have been >>> very clear that it is a storage container for byte sized data, and no >>> automatic conversion (by the compiler) would be done to data stored in >>> such containers. >> >> Call me lazy but I don't want to reinvent the wheel and re-implement >> from scratch the functionality that a plain ansistring provides and >> TBytes to this day doesn't. >> I mean, TBytes is just an "array of char". I can't (easily) add a byte >> to the end, cut a slice of the bytes, find one byte in the array, etc. >> OK, I can, but I have to program it all by myself while a string does >> all that and more and probably it's a lot more efficient. > > Trunk supports Insert() and Delete() on dynamic arrays, Concat() and + > are on the near term ToDo list. I started using strings as communication buffers since delphi 2. There weren't even dynamic arrays then... Bye -- Luca Olivetti Wetron Automation Technology http://www.wetron.es/ Tel. +34 93 5883004 (Ext.3010) Fax +34 93 5883007 From mailinglists at geldenhuys.co.uk Thu Aug 17 01:30:09 2017 From: mailinglists at geldenhuys.co.uk (Graeme Geldenhuys) Date: Thu, 17 Aug 2017 00:30:09 +0100 Subject: [Lazarus] String vs WideString In-Reply-To: References: <1ivuocdrq736eamemh6mp6h9old5omrssn@4ax.com> <38b0193a-eb86-4d6a-6292-f2203daff126@mccallumwhyman.com> <20170814154654.52d5d1d4@limapholos.matflo.wg> <20170815111313.0d368eaf@limapholos.matflo.wg> <49d88133-d578-d80c-c080-58b635602054@lumino.de> <762d5869-d011-a91e-6571-317d4ad01c45@geldenhuys.co.uk> Message-ID: <6b07c392-5a7d-8b99-42cf-a7429425b428@geldenhuys.co.uk> On 2017-08-16 18:35, Sven Barth via Lazarus wrote: > You are wrong. The string types in 3.0.x and 3.1 are like this: Thanks for correcting me. I was thinking of the "$modeswitch unicodestring" option. Regards, Graeme From mailinglists at geldenhuys.co.uk Thu Aug 17 01:34:42 2017 From: mailinglists at geldenhuys.co.uk (Graeme Geldenhuys) Date: Thu, 17 Aug 2017 00:34:42 +0100 Subject: [Lazarus] String vs WideString In-Reply-To: References: <38b0193a-eb86-4d6a-6292-f2203daff126@mccallumwhyman.com> <20170814154654.52d5d1d4@limapholos.matflo.wg> <20170815111313.0d368eaf@limapholos.matflo.wg> <3956bacd-2902-ea33-060b-252de9f97ca5@geldenhuys.co.uk> <66aa5516-1c29-f48e-1337-13abd8413e8d@wetron.es> <624223a6-e1ff-0006-0134-2777ffda4bc8@geldenhuys.co.uk> Message-ID: On 2017-08-16 19:26, Luca Olivetti via Lazarus wrote: > I mean, TBytes is just an "array of char". NO! Char can now mean a 1-byte char or a 2-byte char (I don't know how FPC plans to support Unicode surrogate pairs which will require 4-bytes). In the olden days (Delphi 7 and FPC 2.6.4) the Char type might always have meant 1-byte, but it doesn't necessarily these days. TBytes has always been a container for Byte data. 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 From mailinglists at geldenhuys.co.uk Thu Aug 17 01:38:06 2017 From: mailinglists at geldenhuys.co.uk (Graeme Geldenhuys) Date: Thu, 17 Aug 2017 00:38:06 +0100 Subject: [Lazarus] String vs WideString In-Reply-To: <4bd55f90-8649-94cf-aa97-e4df0786a197@wetron.es> References: <20170814154654.52d5d1d4@limapholos.matflo.wg> <20170815111313.0d368eaf@limapholos.matflo.wg> <3956bacd-2902-ea33-060b-252de9f97ca5@geldenhuys.co.uk> <66aa5516-1c29-f48e-1337-13abd8413e8d@wetron.es> <624223a6-e1ff-0006-0134-2777ffda4bc8@geldenhuys.co.uk> <4bd55f90-8649-94cf-aa97-e4df0786a197@wetron.es> Message-ID: <71470311-447f-9147-8c27-c35f479737d1@geldenhuys.co.uk> On 2017-08-16 23:46, Luca Olivetti via Lazarus wrote: > I started using strings as communication buffers since delphi 2. There > weren't even dynamic arrays then... Well, Link-Lists existed from the beginning of time. I used them plenty in my TP days, and adding, inserting, indexing etc was pretty easy. Maybe programmers have just become spoilt over time with all the "out of the box" functionality and actually become lazy in coding. 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 From wkitty42 at windstream.net Thu Aug 17 04:15:07 2017 From: wkitty42 at windstream.net (wkitty42 at windstream.net) Date: Wed, 16 Aug 2017 22:15:07 -0400 Subject: [Lazarus] String vs WideString In-Reply-To: <6b07c392-5a7d-8b99-42cf-a7429425b428@geldenhuys.co.uk> References: <38b0193a-eb86-4d6a-6292-f2203daff126@mccallumwhyman.com> <20170814154654.52d5d1d4@limapholos.matflo.wg> <20170815111313.0d368eaf@limapholos.matflo.wg> <49d88133-d578-d80c-c080-58b635602054@lumino.de> <762d5869-d011-a91e-6571-317d4ad01c45@geldenhuys.co.uk> <6b07c392-5a7d-8b99-42cf-a7429425b428@geldenhuys.co.uk> Message-ID: On 08/16/2017 07:30 PM, Graeme Geldenhuys via Lazarus wrote: > On 2017-08-16 18:35, Sven Barth via Lazarus wrote: >> You are wrong. The string types in 3.0.x and 3.1 are like this: > > Thanks for correcting me. I was thinking of the "$modeswitch unicodestring" option. will that modeswitch take care of the warning about explicit conversion between ansistring and unicode string when one has var foo : unicodestring; writeln(padright(foo,5); ?? i wrote a quick and simple little array exhibit program for someone... i had thought to try to embrace this new unicode stuff by using unicode strings... the using the padright and similar string manipulators gave me warnings about ansistring conversions :? NOTE: this may be because i have an older lazarus and fpc installed... lazarus fixes 1.6.1 and fpc fixes 3.0.something... -- NOTE: No off-list assistance is given without prior approval. *Please keep mailing list traffic on the list unless* *a signed and pre-paid contract is in effect with us.* From wkitty42 at windstream.net Thu Aug 17 04:17:08 2017 From: wkitty42 at windstream.net (wkitty42 at windstream.net) Date: Wed, 16 Aug 2017 22:17:08 -0400 Subject: [Lazarus] String vs WideString In-Reply-To: <4bd55f90-8649-94cf-aa97-e4df0786a197@wetron.es> References: <20170814154654.52d5d1d4@limapholos.matflo.wg> <20170815111313.0d368eaf@limapholos.matflo.wg> <3956bacd-2902-ea33-060b-252de9f97ca5@geldenhuys.co.uk> <66aa5516-1c29-f48e-1337-13abd8413e8d@wetron.es> <624223a6-e1ff-0006-0134-2777ffda4bc8@geldenhuys.co.uk> <4bd55f90-8649-94cf-aa97-e4df0786a197@wetron.es> Message-ID: <325feab1-8a0d-9252-ec95-907c0bd8935a@windstream.net> On 08/16/2017 06:46 PM, Luca Olivetti via Lazarus wrote: > I started using strings as communication buffers since delphi 2. There > weren't even dynamic arrays then... really? delphi came from TP/BP... i was (still am, actually) using dynamic arrays in TP6 ;) -- NOTE: No off-list assistance is given without prior approval. *Please keep mailing list traffic on the list unless* *a signed and pre-paid contract is in effect with us.* From pascaldragon at googlemail.com Thu Aug 17 07:10:12 2017 From: pascaldragon at googlemail.com (Sven Barth) Date: Thu, 17 Aug 2017 07:10:12 +0200 Subject: [Lazarus] String vs WideString In-Reply-To: <325feab1-8a0d-9252-ec95-907c0bd8935a@windstream.net> References: <20170814154654.52d5d1d4@limapholos.matflo.wg> <20170815111313.0d368eaf@limapholos.matflo.wg> <3956bacd-2902-ea33-060b-252de9f97ca5@geldenhuys.co.uk> <66aa5516-1c29-f48e-1337-13abd8413e8d@wetron.es> <624223a6-e1ff-0006-0134-2777ffda4bc8@geldenhuys.co.uk> <4bd55f90-8649-94cf-aa97-e4df0786a197@wetron.es> <325feab1-8a0d-9252-ec95-907c0bd8935a@windstream.net> Message-ID: Am 17.08.2017 04:16 schrieb "wkitty42--- via Lazarus" < lazarus at lists.lazarus-ide.org>: > > On 08/16/2017 06:46 PM, Luca Olivetti via Lazarus wrote: >> >> I started using strings as communication buffers since delphi 2. There >> weren't even dynamic arrays then... > > > really? delphi came from TP/BP... i was (still am, actually) using dynamic arrays in TP6 ;) Dynamic arrays in the form of "array of Type" were only introduced in Delphi 3 if I remember correctly. Anything before that needed manual memory management. Regards, Sven -------------- next part -------------- An HTML attachment was scrubbed... URL: From mschnell at lumino.de Thu Aug 17 11:02:27 2017 From: mschnell at lumino.de (Michael Schnell) Date: Thu, 17 Aug 2017 11:02:27 +0200 Subject: [Lazarus] dynamic string proposal In-Reply-To: <20170816182457.6275d5a6@limapholos.matflo.wg> References: <20170816115114.06d361db@limapholos.matflo.wg> <5fb059ce-6d78-14e2-614a-e30ec476dd28@lumino.de> <20170816131727.49973c7d@limapholos.matflo.wg> <6b1b26df-7ff6-067d-7b5a-c8be14b7acad@lumino.de> <8fc0a5c0-43d0-6d1b-96ea-05d2daf3862c@lumino.de> <20170816182457.6275d5a6@limapholos.matflo.wg> Message-ID: On 16.08.2017 18:24, Mattias Gaertner via Lazarus wrote: > This "dynamicstring" sounds like Rawbytestring times two. In fact I do suppose that the initial intention the Developers had with Rawbytestring, was something like this, but it never was implemented or documented appropriately. In fact I (no access to XE) don't know hat happens when you do Rawbytestring := SomeDedicatedString. With the DynamicString here the "encoding brand" and "bytes per element" are copied over. AFAIK Rawbytestring never is prone to autoconversion. The goal of DynamicString is exactly the contrary: do autoconversion when necessary. > Any function accessing the inner chars of a "dynamicstring" has to > handleRawbytestring codepages and unicodestring and array of > byte/word/dword. In fact it has to handle the "codepage" etc that is denoted dynamically in the string header. Exactly like with any other string. Only that it can't be determined at compile time. This of course will introduce a small performance degradation (happening only when explicitly DynamicStrings are used). What do you mean by "accessing the inner chars" ? If you do SomeDedicatedString := Rawbytestring, AutoConversion is done necessary (i.e. the (static) encoding brand of the target is not equal the (dynamic) encoding brand of the source, and both are not "Raw" / "binary"). This of course needs appropriate compiler magic. > If this is the price for avoiding some conversions, many programmers > will become unhappy. I don't see, why. > Michael, please tell me your proposal has some serious advantages. I don't see them. Matthias, thanks for taking the effort of evaluating the (weired) suggestion. The paper was the result of several discussions in the fpc forum started by users complaining hat their code did not work any more when compiling with a new version or fpc/Lazarus. - Code ported from older (not Unicode aware) Delphi or fpc versions: forced usage of Unicode functions (e.g. based on TStrings) was not compatible with their usage of one-byte-strings the coding of which was of no concern for the compiler (because it was not necessary) - Code ported from the intermediate Unicode aware Lazarus version that ran with the not Unicode aware fpc: all kinds of problems, a very popular problem at that time. - Code ported from newer (Unicode aware) Delphi versions: problems arising from UTF-8 / UTF-16 differences. And you could not have them just define their strings appropriately to have the Unicode aware fpc behave like the system they produced their code on, as (e.g.) TStrings forcibly requires UTF-8. Hence the ability to allow TStrings (and siblings and in fact any other library function) to handle any encoding / bytes_per_element the user choses for his string functionality, could be a solution. This in place (in fact rethinking the dull encoding-aware-string support Embarcadero forced on their users), the "String" paradigm can be enhanced to allow for additional functionality. E.g.: - Non-Text String elements (such as Bytes, Words, DWord, Qwords, ....) - User defined encoding (the user would be enabled to supply the conversion functions with other string encoding brands he intends to use. -Michael From mschnell at lumino.de Thu Aug 17 11:10:54 2017 From: mschnell at lumino.de (Michael Schnell) Date: Thu, 17 Aug 2017 11:10:54 +0200 Subject: [Lazarus] dynamic string proposal In-Reply-To: <20170816115114.06d361db@limapholos.matflo.wg> References: <20170816115114.06d361db@limapholos.matflo.wg> Message-ID: Maybe, Sven could answer to this mail in the other thread... On 14.08.2017 18:47, Sven Barth via Lazarus wrote: > > The main problem of such a dynamic type would be the inability to do > fast indexing as the compiler would need to insert runtime checks for > the size of a character. > What "indexing" do you think of ? Could you give an example where such a difference is supposed to get important ? (As you know I wrote a paper where I claimed the contrary. I'd like to revise same if necessary.) -Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: From mschnell at lumino.de Thu Aug 17 11:16:21 2017 From: mschnell at lumino.de (Michael Schnell) Date: Thu, 17 Aug 2017 11:16:21 +0200 Subject: [Lazarus] String vs WideString In-Reply-To: References: <38b0193a-eb86-4d6a-6292-f2203daff126@mccallumwhyman.com> <20170814154654.52d5d1d4@limapholos.matflo.wg> <20170815111313.0d368eaf@limapholos.matflo.wg> <3956bacd-2902-ea33-060b-252de9f97ca5@geldenhuys.co.uk> <66aa5516-1c29-f48e-1337-13abd8413e8d@wetron.es> <624223a6-e1ff-0006-0134-2777ffda4bc8@geldenhuys.co.uk> Message-ID: <894d7f5f-a634-bf23-6986-dd4addcda3c4@lumino.de> On 16.08.2017 20:26, Luca Olivetti via Lazarus wrote: > > Call me lazy but I don't want to reinvent the wheel and re-implement > from scratch the functionality that a plain ansistring provides and > TBytes to this day doesn't. So please continue in the thread "dynamic string proposal". Exactly this is part of what is discussed there. -Michael From mschnell at lumino.de Thu Aug 17 11:20:31 2017 From: mschnell at lumino.de (Michael Schnell) Date: Thu, 17 Aug 2017 11:20:31 +0200 Subject: [Lazarus] String vs WideString In-Reply-To: References: <38b0193a-eb86-4d6a-6292-f2203daff126@mccallumwhyman.com> <20170814154654.52d5d1d4@limapholos.matflo.wg> <20170815111313.0d368eaf@limapholos.matflo.wg> <3956bacd-2902-ea33-060b-252de9f97ca5@geldenhuys.co.uk> <66aa5516-1c29-f48e-1337-13abd8413e8d@wetron.es> <624223a6-e1ff-0006-0134-2777ffda4bc8@geldenhuys.co.uk> Message-ID: On 16.08.2017 22:40, Sven Barth via Lazarus wrote: > Trunk supports Insert() and Delete() on dynamic arrays, Concat() and + > are on the near term ToDo list. Supposedly "pos", as well. But that does not really help if we don't have a TStringList workalike, and supposedly several more library functions. That is why I feel empowering the string paradigm for such use would be more appropriate. (See the thread "dynamic string proposal"). -Michael From pascaldragon at googlemail.com Thu Aug 17 11:27:15 2017 From: pascaldragon at googlemail.com (Sven Barth) Date: Thu, 17 Aug 2017 11:27:15 +0200 Subject: [Lazarus] String vs WideString In-Reply-To: References: <38b0193a-eb86-4d6a-6292-f2203daff126@mccallumwhyman.com> <20170814154654.52d5d1d4@limapholos.matflo.wg> <20170815111313.0d368eaf@limapholos.matflo.wg> <3956bacd-2902-ea33-060b-252de9f97ca5@geldenhuys.co.uk> <66aa5516-1c29-f48e-1337-13abd8413e8d@wetron.es> <624223a6-e1ff-0006-0134-2777ffda4bc8@geldenhuys.co.uk> Message-ID: Am 17.08.2017 11:21 schrieb "Michael Schnell via Lazarus" < lazarus at lists.lazarus-ide.org>: > > On 16.08.2017 22:40, Sven Barth via Lazarus wrote: >> >> Trunk supports Insert() and Delete() on dynamic arrays, Concat() and + are on the near term ToDo list. > > > Supposedly "pos", as well. But that does not really help if we don't have a TStringList workalike, and supposedly several more library functions. > > That is why I feel empowering the string paradigm for such use would be more appropriate. (See the thread "dynamic string proposal"). Why do you want to stuff everything and the kitchen sink into TStrings? There are much more suitable and less specialized container types available for this (to name a few: TFPGList, TList<>, etc.). Regards, Sven -------------- next part -------------- An HTML attachment was scrubbed... URL: From pascaldragon at googlemail.com Thu Aug 17 11:29:40 2017 From: pascaldragon at googlemail.com (Sven Barth) Date: Thu, 17 Aug 2017 11:29:40 +0200 Subject: [Lazarus] dynamic string proposal In-Reply-To: References: <20170816115114.06d361db@limapholos.matflo.wg> Message-ID: Am 17.08.2017 11:11 schrieb "Michael Schnell via Lazarus" < lazarus at lists.lazarus-ide.org>: > > Maybe, Sven could answer to this mail in the other thread... > I provided an example in my answer to Tony Whyman in the same subbranch of the thread. Regards, Sven -------------- next part -------------- An HTML attachment was scrubbed... URL: From mschnell at lumino.de Thu Aug 17 11:41:10 2017 From: mschnell at lumino.de (Michael Schnell) Date: Thu, 17 Aug 2017 11:41:10 +0200 Subject: [Lazarus] dynamic string proposal In-Reply-To: References: <20170816115114.06d361db@limapholos.matflo.wg> Message-ID: <2fbf072a-83f5-490b-7686-712669577ca3@lumino.de> On 17.08.2017 11:29, Sven Barth via Lazarus wrote: > > Am 17.08.2017 11:11 schrieb "Michael Schnell via Lazarus" > >: > > > > Maybe, Sven could answer to this mail in the other thread... > > > > I provided an example in my answer to Tony Whyman in the same > subbranch of the thread. > I suppose you mean this: > In a tight loop where one accesss the string character by character > (take Pos() for example) this will lead to a significant slowdown as the > compiler (without optimizations) will have to insert a call to the > lookup function for each access. While I generally don't consider > performance degradation as a backwards compatibility issue I do in this > case, due to the significant decrease in performance. This is not applicable to the "DynamicString" discussed here. With that, "pos" would just need to use the "bytes per element" value taken (once) from the the String header, instead of a value supplied at compile time. I don't think that this can introduce a considerable performance hit. -Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: From bartjunk64 at gmail.com Thu Aug 17 12:09:02 2017 From: bartjunk64 at gmail.com (Bart) Date: Thu, 17 Aug 2017 12:09:02 +0200 Subject: [Lazarus] String vs WideString In-Reply-To: <4bd55f90-8649-94cf-aa97-e4df0786a197@wetron.es> References: <38b0193a-eb86-4d6a-6292-f2203daff126@mccallumwhyman.com> <20170814154654.52d5d1d4@limapholos.matflo.wg> <20170815111313.0d368eaf@limapholos.matflo.wg> <3956bacd-2902-ea33-060b-252de9f97ca5@geldenhuys.co.uk> <66aa5516-1c29-f48e-1337-13abd8413e8d@wetron.es> <624223a6-e1ff-0006-0134-2777ffda4bc8@geldenhuys.co.uk> <4bd55f90-8649-94cf-aa97-e4df0786a197@wetron.es> Message-ID: On 8/17/17, Luca Olivetti via Lazarus wrote: > I started using strings as communication buffers since delphi 2. There > weren't even dynamic arrays then... >From the Turbo Pascal Help: "A string type variable is a sequence of characters ..." And then when you click on "characters": "Char type ----------- Variables of the ordinal type Char are used to store ASCII characters." None of this suggests that string is a good type for storing arbitrary byte sequences. You misused an implementation detail of the type (Ansi)String. And now you blame fpc. You should have used a sane type for your buffer from the start. Bart From bartjunk64 at gmail.com Thu Aug 17 12:17:12 2017 From: bartjunk64 at gmail.com (Bart) Date: Thu, 17 Aug 2017 12:17:12 +0200 Subject: [Lazarus] String vs WideString In-Reply-To: References: <20170814154654.52d5d1d4@limapholos.matflo.wg> <20170815111313.0d368eaf@limapholos.matflo.wg> <3956bacd-2902-ea33-060b-252de9f97ca5@geldenhuys.co.uk> <66aa5516-1c29-f48e-1337-13abd8413e8d@wetron.es> <624223a6-e1ff-0006-0134-2777ffda4bc8@geldenhuys.co.uk> <4bd55f90-8649-94cf-aa97-e4df0786a197@wetron.es> <325feab1-8a0d-9252-ec95-907c0bd8935a@windstream.net> Message-ID: On 8/17/17, Sven Barth via Lazarus wrote: >> really? delphi came from TP/BP... i was (still am, actually) using > dynamic arrays in TP6 ;) > > Dynamic arrays in the form of "array of Type" were only introduced in > Delphi 3 if I remember correctly. Anything before that needed manual memory > management. I had D3 Pro, and this did definitively NOT support dynamic arrays. (Even String still was ShortString.) All arrays had to be fixed range. The often used construct to bypass this limitation was: Array[0..0] of TSomeType and have Range checking of. Bart From tony.whyman at mccallumwhyman.com Thu Aug 17 12:41:03 2017 From: tony.whyman at mccallumwhyman.com (Tony Whyman) Date: Thu, 17 Aug 2017 11:41:03 +0100 Subject: [Lazarus] String vs WideString In-Reply-To: References: <20170812223247.73330e02@limapholos.matflo.wg> <20170812224956.4e624b23@limapholos.matflo.wg> <1ivuocdrq736eamemh6mp6h9old5omrssn@4ax.com> <38b0193a-eb86-4d6a-6292-f2203daff126@mccallumwhyman.com> <20170814154654.52d5d1d4@limapholos.matflo.wg> Message-ID: <08ed778e-1db6-c2d6-2c55-c21fdee67272@mccallumwhyman.com> On 16/08/17 11:05, Juha Manninen via Lazarus wrote: > On Mon, Aug 14, 2017 at 4:21 PM, Tony Whyman via Lazarus > wrote: >> UTF-16/Unicode can only store 65,536 characters while the Unicode standard >> (that covers UTF8 as well) defines 136,755 characters. >> UTF-16/Unicode's main advantage seems to be for rapid indexing of large >> strings. > That shows complete ignorance from your side about Unicode. > You consider UTF-16 as a fixed-width encoding. :( > Unfortunately many other programmers had the same wrong idea or they > were just lazy. The result anyway is a lot of broken UTF-16 code out > there. You do like to use the word "ignorance" don't you. You can if you want take the view that all the "other programmers" that got the wrong idea are "stupid monkeys that don't know any better" or, alternatively, that they just wanted a nice cup of tea rather than the not quite tea drink that was served up. Wikipedia sums the problem up nicely: "The early 2-byte encoding was usually called "Unicode", but is now called "UCS-2". UCS-2 differs from UTF-16 by being a constant length encoding and only capable of encoding characters of BMP, it is supported by many programs." This is where the problem starts. The definitive of "Unicode" was changed (foolishly in my opinion) after it had been accepted by the community and the result is confusion. Hence my first point about not even using it. In using "UTF16/Unicode" I was attempting to convey the common use of the term which is to see UTF-16 as what is now defined as UCS-2. This is because hardly anyone I know uses UCS-2 and instead says "Unicode". Perhaps I just spend too much time amongst the ignorant. Wikipedia also makes the wonderful point that "The UTF-16 encoding scheme was developed as a compromise to resolve this impasse in version 2.0". The impasse having resulted from "4 bytes per character wasted a lot of disk space and memory, and because some manufacturers were already heavily invested in 2-byte-per-character technology". Finally: "In UTF-16, code points greater or equal to 2^16 are encoded using /two/ 16-bit code units. The standards organizations chose the largest block available of un-allocated 16-bit code points to use as these code units (since most existing UCS-2 data did not use these code points and would be valid UTF-16). Unlike UTF-8 they did not provide a means to encode these code points". Which is from where I get my own view that UTF-16, as defined by the standards, is pointless. If you keep it to a UCS-2 (like) subset then you can get rapid indexing of character arrays. But as soon as you introduce the possibility of some characters being encoded as two 16-bit units then you lose rapid indexing and I can see no advantage over UTF-8 - plus you get all the fun of worrying about byte order. Indeed, I believe those lazy programmers that you referred to, are actually making a conscious decision to prefer to work with a 16-bit code point only UTF-16 subset (i.e. the Basic Multilingual Plan) precisely so that they can do rapid indexing. As soon as you bring in 2 x 16-bit code unit code points, you lose that benefit - and perhaps you should be using UTF-32. IMHO, Linux has got it right by using UTF-8 as the standard for character encoding and one of Lazarus's USPs is that it follows that lead - even for Windows. I can see why a program that does intensive text scanning will use a UTF-16 constrained to the BMP (i.e. 16-bit only), but not why anyone would prefer an unconstrained UTF-16 over UTF-8. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tony.whyman at mccallumwhyman.com Thu Aug 17 13:09:08 2017 From: tony.whyman at mccallumwhyman.com (Tony Whyman) Date: Thu, 17 Aug 2017 12:09:08 +0100 Subject: [Lazarus] String vs WideString In-Reply-To: References: <20170812223247.73330e02@limapholos.matflo.wg> <20170812224956.4e624b23@limapholos.matflo.wg> <1ivuocdrq736eamemh6mp6h9old5omrssn@4ax.com> <38b0193a-eb86-4d6a-6292-f2203daff126@mccallumwhyman.com> <20170814154654.52d5d1d4@limapholos.matflo.wg> Message-ID: <5b3eb4e8-9b51-f79b-460c-f72aae1d2033@mccallumwhyman.com> On 16/08/17 11:05, Juha Manninen via Lazarus wrote: > 2. Clean up the char type. >> ... >> Why shouldn't there be a single char type that intuitively represents >> a single character regardless of how many bytes are used to represent it. > What do you mean by "a single character"? > A "character" in Unicode can mean about 7 different things. Which one > is your pick? > This question is for everybody in this thread who used the word "character". Are you making my points for me? If such a basic term as "character" means 7 different things then something is badly amiss. It should be fairly obvious that in this context, character = printable symbol - whilst for practical reasons allowing for format control characters such as a "end of line" and "end of string". I believe that you need to go back to the idea that you have both an abstract representation of a character with a constant semantic, separate from the actual encoding and for which there may be many different and valid encodings. For example, using a somewhat dated comparison, a lower case latin alphabet letter 'a' should always have a constant semantic, but in ASCII is encoded as decimal 97, while in EBCDIC is encoded as decimal 129. Even though they have different binary values, the represent the same abstract character. I want a 'char' type in Pascal to represent a character such as a lower case 'a' regardless of the encoding used. Indeed, for a program to be properly portable, the programmer should not have to care are the actual encoding - only that it is a lower case 'a'. Hence my proposal that a character type should include an implicit or explicit attribute that records the encoding scheme used - which could vary from ASCII to UTF-32. You can then go on to define a text string as an array of characters with the same encoding scheme. > >> Yes, in a world where we have to live with UTF8, UTF16, UTF32, legacy code >> pages and Chinese variations on UTF8, that means that dynamic attributes >> have to be included in the type. But isn't that the only way to have >> consistent and intuitive character handling? > What do you mean? Chinese don't have a variation of UTF8. > UTF8 is global unambiguous encoding standard, part of Unicode. I was referring to GB 18030 and that it has one, two and four byte code points. > > The fundamental problem is that you want to hide the complexity of > Unicode by some magic String type of a compiler. > It is not possible. Unicode remains complex but the complexity is NOT > in encodings! > No, a codepoint's encoding is the easy part. For example I was easily > able to create a unit to support encoding agnostic code. See unit > LazUnicode in package LazUtils. > The complexity is elsewhere: > - "Character" composed of codepoints in precomposed and decomposed > (normalized) forms. > - Compare and sort text based on locale. > - Uppercase / Lowercase rules based on locale. > - Glyphs > - Graphemes > - etc. > > I must admit I don't understand well those complex parts. > I do understand codeunits and codepoints, and I understand they are > the easy part. > > Juha The point I believe that you are missing is to consider that a character is an abstract symbol with a semantic independent of how it is encoded. Collation sequences are independent of encoding and should remain the same regardless of how a character set is encoded. From mschnell at lumino.de Thu Aug 17 14:31:13 2017 From: mschnell at lumino.de (Michael Schnell) Date: Thu, 17 Aug 2017 14:31:13 +0200 Subject: [Lazarus] String vs WideString In-Reply-To: References: <20170814154654.52d5d1d4@limapholos.matflo.wg> <20170815111313.0d368eaf@limapholos.matflo.wg> <3956bacd-2902-ea33-060b-252de9f97ca5@geldenhuys.co.uk> <66aa5516-1c29-f48e-1337-13abd8413e8d@wetron.es> <624223a6-e1ff-0006-0134-2777ffda4bc8@geldenhuys.co.uk> <4bd55f90-8649-94cf-aa97-e4df0786a197@wetron.es> Message-ID: On 17.08.2017 12:09, Bart via Lazarus wrote: > > Variables of the ordinal type Char are used to store ASCII characters." > > According to this wording, using Windows with ANSI character set would be a no-go. -Michael From mschnell at lumino.de Thu Aug 17 14:35:58 2017 From: mschnell at lumino.de (Michael Schnell) Date: Thu, 17 Aug 2017 14:35:58 +0200 Subject: [Lazarus] String vs WideString In-Reply-To: <08ed778e-1db6-c2d6-2c55-c21fdee67272@mccallumwhyman.com> References: <20170812223247.73330e02@limapholos.matflo.wg> <20170812224956.4e624b23@limapholos.matflo.wg> <1ivuocdrq736eamemh6mp6h9old5omrssn@4ax.com> <38b0193a-eb86-4d6a-6292-f2203daff126@mccallumwhyman.com> <20170814154654.52d5d1d4@limapholos.matflo.wg> <08ed778e-1db6-c2d6-2c55-c21fdee67272@mccallumwhyman.com> Message-ID: On 17.08.2017 12:41, Tony Whyman via Lazarus wrote: > > UCS-2 differs from UTF-16 by being a constant length encoding and only > capable of encoding characters of BMP, it is supported by many programs." Rather obviously Embarcadero primarily had UCS-2 in mind as they created the "Unicode aware" Delphi. While it in fact does support full Unicode, keeping MyChar:=MyString[i] in place suggests to presume UCS-2 coded text for "unaware" programmers. -Michael From mschnell at lumino.de Thu Aug 17 14:40:12 2017 From: mschnell at lumino.de (Michael Schnell) Date: Thu, 17 Aug 2017 14:40:12 +0200 Subject: [Lazarus] String vs WideString In-Reply-To: <08ed778e-1db6-c2d6-2c55-c21fdee67272@mccallumwhyman.com> References: <20170812223247.73330e02@limapholos.matflo.wg> <20170812224956.4e624b23@limapholos.matflo.wg> <1ivuocdrq736eamemh6mp6h9old5omrssn@4ax.com> <38b0193a-eb86-4d6a-6292-f2203daff126@mccallumwhyman.com> <20170814154654.52d5d1d4@limapholos.matflo.wg> <08ed778e-1db6-c2d6-2c55-c21fdee67272@mccallumwhyman.com> Message-ID: <827d76a0-1344-91a6-dab6-06d17665fc2f@lumino.de> On 17.08.2017 12:41, Tony Whyman via Lazarus wrote: > > Finally: "In UTF-16, code points greater or equal to 2^16 are encoded > using /two/ 16-bit code units. 2¹⁵ ??? -Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: From md at delfire.net Thu Aug 17 14:40:44 2017 From: md at delfire.net (Marcos Douglas B. Santos) Date: Thu, 17 Aug 2017 09:40:44 -0300 Subject: [Lazarus] String vs WideString In-Reply-To: References: <20170812223247.73330e02@limapholos.matflo.wg> <20170812224956.4e624b23@limapholos.matflo.wg> <1ivuocdrq736eamemh6mp6h9old5omrssn@4ax.com> <38b0193a-eb86-4d6a-6292-f2203daff126@mccallumwhyman.com> Message-ID: On Wed, Aug 16, 2017 at 12:38 PM, Juha Manninen via Lazarus wrote: > On Wed, Aug 16, 2017 at 5:48 PM, Marcos Douglas B. Santos via Lazarus >> Are you saying that I need to do this? >> (following the firt example on this thread) > > No, if the parameter is WideString, not a pointer PWideChar, you can > just call it like you did. Suppress the warning as Mattias told if it > bothers you. You can also make a helper function so the conversion > happens in one place. > Yes, for OLE you need WideString. "Suppress the warning as Mattias told if it bothers you" Of course bothers me. Sorry, but every single warning is a... warning... that needs to be resolved. If this is not a problem (or a possible future problem), the compiler should not give us a warning, right? Best regards, Marcos Douglas From pascaldragon at googlemail.com Thu Aug 17 14:43:04 2017 From: pascaldragon at googlemail.com (Sven Barth) Date: Thu, 17 Aug 2017 14:43:04 +0200 Subject: [Lazarus] dynamic string proposal In-Reply-To: <2fbf072a-83f5-490b-7686-712669577ca3@lumino.de> References: <20170816115114.06d361db@limapholos.matflo.wg> <2fbf072a-83f5-490b-7686-712669577ca3@lumino.de> Message-ID: Am 17.08.2017 11:41 schrieb "Michael Schnell via Lazarus" < lazarus at lists.lazarus-ide.org>: > > On 17.08.2017 11:29, Sven Barth via Lazarus wrote: >> >> Am 17.08.2017 11:11 schrieb "Michael Schnell via Lazarus" < lazarus at lists.lazarus-ide.org>: >> > >> > Maybe, Sven could answer to this mail in the other thread... >> > >> >> I provided an example in my answer to Tony Whyman in the same subbranch of the thread. > > > I suppose you mean this: >> >> In a tight loop where one accesss the string character by character (take Pos() for example) this will lead to a significant slowdown as the compiler (without optimizations) will have to insert a call to the lookup function for each access. While I generally don't consider performance degradation as a backwards compatibility issue I do in this case, due to the significant decrease in performance. > > This is not applicable to the "DynamicString" discussed here. With that, "pos" would just need to use the "bytes per element" value taken (once) from the the String header, instead of a value supplied at compile time. I don't think that this can introduce a considerable performance hit. Yes it does, because without optimizations implemented and enabled the compiler would need to do this for each element access. Regards, Sven -------------- next part -------------- An HTML attachment was scrubbed... URL: From pascaldragon at googlemail.com Thu Aug 17 14:46:33 2017 From: pascaldragon at googlemail.com (Sven Barth) Date: Thu, 17 Aug 2017 14:46:33 +0200 Subject: [Lazarus] String vs WideString In-Reply-To: References: <20170814154654.52d5d1d4@limapholos.matflo.wg> <20170815111313.0d368eaf@limapholos.matflo.wg> <3956bacd-2902-ea33-060b-252de9f97ca5@geldenhuys.co.uk> <66aa5516-1c29-f48e-1337-13abd8413e8d@wetron.es> <624223a6-e1ff-0006-0134-2777ffda4bc8@geldenhuys.co.uk> <4bd55f90-8649-94cf-aa97-e4df0786a197@wetron.es> Message-ID: Am 17.08.2017 14:32 schrieb "Michael Schnell via Lazarus" < lazarus at lists.lazarus-ide.org>: > > On 17.08.2017 12:09, Bart via Lazarus wrote: >> >> >> Variables of the ordinal type Char are used to store ASCII characters." >> >> > According to this wording, using Windows with ANSI character set would be a no-go. Bart quoted from the TP help. And TP was written for DOS. There wasn't any Unicode or ANSI around yet... Regards Sven -------------- next part -------------- An HTML attachment was scrubbed... URL: From pascaldragon at googlemail.com Thu Aug 17 14:47:13 2017 From: pascaldragon at googlemail.com (Sven Barth) Date: Thu, 17 Aug 2017 14:47:13 +0200 Subject: [Lazarus] String vs WideString In-Reply-To: References: <20170814154654.52d5d1d4@limapholos.matflo.wg> <20170815111313.0d368eaf@limapholos.matflo.wg> <3956bacd-2902-ea33-060b-252de9f97ca5@geldenhuys.co.uk> <66aa5516-1c29-f48e-1337-13abd8413e8d@wetron.es> <624223a6-e1ff-0006-0134-2777ffda4bc8@geldenhuys.co.uk> <4bd55f90-8649-94cf-aa97-e4df0786a197@wetron.es> <325feab1-8a0d-9252-ec95-907c0bd8935a@windstream.net> Message-ID: Am 17.08.2017 12:17 schrieb "Bart via Lazarus" < lazarus at lists.lazarus-ide.org>: > > On 8/17/17, Sven Barth via Lazarus wrote: > > >> really? delphi came from TP/BP... i was (still am, actually) using > > dynamic arrays in TP6 ;) > > > > Dynamic arrays in the form of "array of Type" were only introduced in > > Delphi 3 if I remember correctly. Anything before that needed manual memory > > management. > > I had D3 Pro, and this did definitively NOT support dynamic arrays. > (Even String still was ShortString.) > All arrays had to be fixed range. > The often used construct to bypass this limitation was: Array[0..0] of > TSomeType and have Range checking of. Then it was Delphi 4 ^^' Regards, Sven -------------- next part -------------- An HTML attachment was scrubbed... URL: From mschnell at lumino.de Thu Aug 17 14:51:44 2017 From: mschnell at lumino.de (Michael Schnell) Date: Thu, 17 Aug 2017 14:51:44 +0200 Subject: [Lazarus] dynamic string proposal In-Reply-To: References: <20170816115114.06d361db@limapholos.matflo.wg> <2fbf072a-83f5-490b-7686-712669577ca3@lumino.de> Message-ID: On 17.08.2017 14:43, Sven Barth via Lazarus wrote: > > Yes it does, because without optimizations implemented and enabled the > compiler would need to do this for each element access. > But it does not need to do a function call. If getting the element size of a string is a pascal function it would be built-in. Moreover I suppose (or suggest) that pos() is a built-in function that in fact can use decently optimized code. Also a library function could use optimized pascal code that reads the element size, stores it in a variable and uses a pointer within the loop. Of course a user function would just do s[x] and see some degradation. -Michael From mse00000 at gmail.com Thu Aug 17 15:11:18 2017 From: mse00000 at gmail.com (Martin Schreiber) Date: Thu, 17 Aug 2017 15:11:18 +0200 Subject: [Lazarus] String vs WideString In-Reply-To: References: <4bd55f90-8649-94cf-aa97-e4df0786a197@wetron.es> Message-ID: <201708171511.18537.mse00000@gmail.com> On Thursday 17 August 2017 12:09:02 Bart via Lazarus wrote: > On 8/17/17, Luca Olivetti via Lazarus wrote: > > I started using strings as communication buffers since delphi 2. There > > weren't even dynamic arrays then... > > From the Turbo Pascal Help: > > "A string type variable is a sequence of characters ..." > > And then when you click on "characters": > > "Char type > ----------- > Variables of the ordinal type Char are used to store ASCII characters." > > None of this suggests that string is a good type for storing arbitrary > byte sequences. > > You misused an implementation detail of the type (Ansi)String. > And now you blame fpc. > > You should have used a sane type for your buffer from the start. > There was none at the start. Martin From mailinglists at geldenhuys.co.uk Thu Aug 17 16:34:35 2017 From: mailinglists at geldenhuys.co.uk (Graeme Geldenhuys) Date: Thu, 17 Aug 2017 15:34:35 +0100 Subject: [Lazarus] String vs WideString In-Reply-To: References: <20170812223247.73330e02@limapholos.matflo.wg> <20170812224956.4e624b23@limapholos.matflo.wg> <1ivuocdrq736eamemh6mp6h9old5omrssn@4ax.com> <38b0193a-eb86-4d6a-6292-f2203daff126@mccallumwhyman.com> Message-ID: <054e2d45-8384-063c-658a-a69bc5fbc684@geldenhuys.co.uk> On 2017-08-17 13:40, Marcos Douglas B. Santos via Lazarus wrote: > Sorry, but every single warning is a... warning... that needs to be > resolved. I feel exactly the same. :-) It took me ages to figure out how to change my code so I could get rid of the "variable not initialized" whenever you used FillChar(). 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 From wkitty42 at windstream.net Thu Aug 17 18:52:55 2017 From: wkitty42 at windstream.net (wkitty42 at windstream.net) Date: Thu, 17 Aug 2017 12:52:55 -0400 Subject: [Lazarus] String vs WideString In-Reply-To: References: <20170814154654.52d5d1d4@limapholos.matflo.wg> <20170815111313.0d368eaf@limapholos.matflo.wg> <3956bacd-2902-ea33-060b-252de9f97ca5@geldenhuys.co.uk> <66aa5516-1c29-f48e-1337-13abd8413e8d@wetron.es> <624223a6-e1ff-0006-0134-2777ffda4bc8@geldenhuys.co.uk> <4bd55f90-8649-94cf-aa97-e4df0786a197@wetron.es> <325feab1-8a0d-9252-ec95-907c0bd8935a@windstream.net> Message-ID: <820b4c25-a4fb-e0a4-2285-e3725212712b@windstream.net> On 08/17/2017 01:10 AM, Sven Barth via Lazarus wrote: > Am 17.08.2017 04:16 schrieb "wkitty42--- via Lazarus" > > On 08/16/2017 06:46 PM, Luca Olivetti via Lazarus wrote: > >> I started using strings as communication buffers since delphi 2. There > >> weren't even dynamic arrays then... > > > > really? delphi came from TP/BP... i was (still am, actually) using dynamic > > arrays in TP6 ;) > > Dynamic arrays in the form of "array of Type" were only introduced in Delphi 3 > if I remember correctly. Anything before that needed manual memory management. IIRC, we do it with var foo : array[0..0] of blerg; and yes, we had/have to be very careful... i think range checking had to be off, also, because the additional elements were outside of the declared compile time range... we didn't have anything like setlength() to adjust the range at that time... -- NOTE: No off-list assistance is given without prior approval. *Please keep mailing list traffic on the list unless* *a signed and pre-paid contract is in effect with us.* From lazarus at kluug.net Thu Aug 17 18:59:38 2017 From: lazarus at kluug.net (Ondrej Pokorny) Date: Thu, 17 Aug 2017 18:59:38 +0200 Subject: [Lazarus] String vs WideString In-Reply-To: <054e2d45-8384-063c-658a-a69bc5fbc684@geldenhuys.co.uk> References: <20170812224956.4e624b23@limapholos.matflo.wg> <1ivuocdrq736eamemh6mp6h9old5omrssn@4ax.com> <38b0193a-eb86-4d6a-6292-f2203daff126@mccallumwhyman.com> <054e2d45-8384-063c-658a-a69bc5fbc684@geldenhuys.co.uk> Message-ID: On 17.08.2017 16:34, Graeme Geldenhuys via Lazarus wrote: > On 2017-08-17 13:40, Marcos Douglas B. Santos via Lazarus wrote: >> Sorry, but every single warning is a... warning... that needs to be >> resolved. > > > I feel exactly the same. :-) It took me ages to figure out how to > change my code so I could get rid of the "variable not initialized" > whenever you used FillChar(). And what do you use? The Default() intrinsic function? Ondrej From aaa5500 at ya.ru Thu Aug 17 20:04:21 2017 From: aaa5500 at ya.ru (Alexey) Date: Thu, 17 Aug 2017 21:04:21 +0300 Subject: [Lazarus] dynamic string proposal In-Reply-To: <9e1670b3-1820-684a-0201-11f103c6dcc9@mfriebe.de> References: <20170816115114.06d361db@limapholos.matflo.wg> <596475ad-3d21-e62d-8797-ea68e5739bfb@mfriebe.de> <9e1670b3-1820-684a-0201-11f103c6dcc9@mfriebe.de> Message-ID: On 16.08.2017 17:36, Martin Frb via Lazarus wrote: > There is ONE character, that comprises more than 200 codepoints. > Only way to store such a char is in a type of dynamic size (aka string) Interesting inf, thanks; so that my idea is not ok for new FPC type. it is ok only for some class, which adds enumerator to take "char" (like you told) of type string. This class not needed in fpc -- Regards, Alexey From luca at wetron.es Thu Aug 17 22:02:09 2017 From: luca at wetron.es (Luca Olivetti) Date: Thu, 17 Aug 2017 22:02:09 +0200 Subject: [Lazarus] String vs WideString In-Reply-To: References: <38b0193a-eb86-4d6a-6292-f2203daff126@mccallumwhyman.com> <20170814154654.52d5d1d4@limapholos.matflo.wg> <20170815111313.0d368eaf@limapholos.matflo.wg> <3956bacd-2902-ea33-060b-252de9f97ca5@geldenhuys.co.uk> <66aa5516-1c29-f48e-1337-13abd8413e8d@wetron.es> <624223a6-e1ff-0006-0134-2777ffda4bc8@geldenhuys.co.uk> Message-ID: <49d1e59e-8af2-0acd-06b2-49d3be7b94b6@wetron.es> El 17/08/17 a les 01:34, Graeme Geldenhuys via Lazarus ha escrit: > On 2017-08-16 19:26, Luca Olivetti via Lazarus wrote: >> I mean, TBytes is just an "array of char". > > NO! Char can now mean a 1-byte char or a 2-byte char (I don't know how Sorry, I meant "array of byte". The point is it doesn't have all the features of a string. Bye -- Luca Olivetti Wetron Automation Technology http://www.wetron.es/ Tel. +34 93 5883004 (Ext.3010) Fax +34 93 5883007 From mailinglists at geldenhuys.co.uk Fri Aug 18 01:12:05 2017 From: mailinglists at geldenhuys.co.uk (Graeme Geldenhuys) Date: Fri, 18 Aug 2017 00:12:05 +0100 Subject: [Lazarus] String vs WideString In-Reply-To: References: <20170812224956.4e624b23@limapholos.matflo.wg> <1ivuocdrq736eamemh6mp6h9old5omrssn@4ax.com> <38b0193a-eb86-4d6a-6292-f2203daff126@mccallumwhyman.com> <054e2d45-8384-063c-658a-a69bc5fbc684@geldenhuys.co.uk> Message-ID: On 2017-08-17 17:59, Ondrej Pokorny via Lazarus wrote: >> change my code so I could get rid of the "variable not initialized" >> whenever you used FillChar(). > And what do you use? I implemented a FillMem() function that calls FillChar(). The parameter are differently defined. Then changed my code as follows: var msgp: TfpgMessageParams; begin - fillchar(msgp, sizeof(msgp), 0); + FillMem(@msgp, sizeof(msgp), 0); msgp.user.Param1 := 2; msgp.user.Param2 := x+10; Finally that warning disappeared. The FillMem() implementation is as follows: procedure FillMem(Dest: pointer; Size: longint; Data: Byte); begin FillChar( Dest^, Size, Data ); end; 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 From tony.whyman at mccallumwhyman.com Fri Aug 18 10:16:24 2017 From: tony.whyman at mccallumwhyman.com (Tony Whyman) Date: Fri, 18 Aug 2017 09:16:24 +0100 Subject: [Lazarus] String vs WideString In-Reply-To: <827d76a0-1344-91a6-dab6-06d17665fc2f@lumino.de> References: <20170812224956.4e624b23@limapholos.matflo.wg> <1ivuocdrq736eamemh6mp6h9old5omrssn@4ax.com> <38b0193a-eb86-4d6a-6292-f2203daff126@mccallumwhyman.com> <20170814154654.52d5d1d4@limapholos.matflo.wg> <08ed778e-1db6-c2d6-2c55-c21fdee67272@mccallumwhyman.com> <827d76a0-1344-91a6-dab6-06d17665fc2f@lumino.de> Message-ID: Damn, should remember never to copy and paste from Wikipedia! On 17/08/17 13:40, Michael Schnell via Lazarus wrote: > On 17.08.2017 12:41, Tony Whyman via Lazarus wrote: >> >> Finally: "In UTF-16, code points greater or equal to 2^16 are encoded >> using /two/ 16-bit code units. > 2¹⁵ ??? > -Michael > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mschnell at lumino.de Fri Aug 18 10:42:16 2017 From: mschnell at lumino.de (Michael Schnell) Date: Fri, 18 Aug 2017 10:42:16 +0200 Subject: [Lazarus] String vs WideString In-Reply-To: References: <20170814154654.52d5d1d4@limapholos.matflo.wg> <20170815111313.0d368eaf@limapholos.matflo.wg> <3956bacd-2902-ea33-060b-252de9f97ca5@geldenhuys.co.uk> <66aa5516-1c29-f48e-1337-13abd8413e8d@wetron.es> <624223a6-e1ff-0006-0134-2777ffda4bc8@geldenhuys.co.uk> Message-ID: <9d7ba4a1-7382-cbbb-0897-6f8d8fe386ce@lumino.de> On 17.08.2017 11:27, Sven Barth via Lazarus wrote: > > Why do you want to stuff everything and the kitchen sink into TStrings? > To make use of the benefits the string type offers such as reference counting and lazy copy. -Michael From mailinglists at geldenhuys.co.uk Fri Aug 18 11:01:43 2017 From: mailinglists at geldenhuys.co.uk (Graeme Geldenhuys) Date: Fri, 18 Aug 2017 10:01:43 +0100 Subject: [Lazarus] String vs WideString In-Reply-To: References: <20170812224956.4e624b23@limapholos.matflo.wg> <1ivuocdrq736eamemh6mp6h9old5omrssn@4ax.com> <38b0193a-eb86-4d6a-6292-f2203daff126@mccallumwhyman.com> <20170814154654.52d5d1d4@limapholos.matflo.wg> <08ed778e-1db6-c2d6-2c55-c21fdee67272@mccallumwhyman.com> <827d76a0-1344-91a6-dab6-06d17665fc2f@lumino.de> Message-ID: On 2017-08-18 09:16, Tony Whyman via Lazarus wrote: > Damn, should remember never to copy and paste from Wikipedia! Or simply use "plain text" emails to this mailing list. It reduces size considerably, and is still perfectly readable (like it has been for the last 30 years in email communications). https://en.wikipedia.org/wiki/ASCII_Ribbon_Campaign ;-) Regards, Graeme From juha.manninen62 at gmail.com Fri Aug 18 11:42:22 2017 From: juha.manninen62 at gmail.com (Juha Manninen) Date: Fri, 18 Aug 2017 12:42:22 +0300 Subject: [Lazarus] dynamic string proposal In-Reply-To: References: <20170816115114.06d361db@limapholos.matflo.wg> <596475ad-3d21-e62d-8797-ea68e5739bfb@mfriebe.de> <9e1670b3-1820-684a-0201-11f103c6dcc9@mfriebe.de> Message-ID: I answer here Tony's post in "String vs WideString" thread. On Thu, Aug 17, 2017 at 2:09 PM, Tony Whyman via Lazarus wrote: > Are you making my points for me? If such a basic term as "character" means 7 > different things then something is badly amiss. It should be fairly obvious > that in this context, character = printable symbol - whilst for practical > reasons allowing for format control characters such as a "end of line" and > "end of string". So, maybe it is the "User-perceived character" from my list above. > I believe that you need to go back to the idea that you have both an > abstract representation of a character with a constant semantic, separate > from the actual encoding and for which there may be many different and valid > encodings. For example, using a somewhat dated comparison, a lower case > latin alphabet letter 'a' should always have a constant semantic, but in > ASCII is encoded as decimal 97, while in EBCDIC is encoded as decimal 129. > Even though they have different binary values, the represent the same > abstract character. > > I want a 'char' type in Pascal to represent a character such as a lower case > 'a' regardless of the encoding used. Indeed, for a program to be properly > portable, the programmer should not have to care are the actual encoding - > only that it is a lower case 'a'. > > Hence my proposal that a character type should include an implicit or > explicit attribute that records the encoding scheme used - which could vary > from ASCII to UTF-32. You use words "character" and "encoding" in the same sentences, although only codepoints are encoded. Codepoints are the easy part anyway. A "character" can be composed of many codepoints and the rules for that are complex and depend on locale. It is not only about combining accent marks, some languages have rules about grapheme clusters etc. (which I don't know well). > I was referring to GB 18030 and that it has one, two and four byte > code points. Ok, I didn't know that one. If I understand right, it is not part of Unicode. > The point I believe that you are missing is to consider that a character is > an abstract symbol with a semantic independent of how it is encoded. > Collation sequences are independent of encoding and should remain the same > regardless of how a character set is encoded. Above I used concepts and terms of Unicode. Maybe your idea is to create another abstract system outside of Unicode. The problem is that the complex rules of Unicode are needed to support all the languages in the world. Your new abstract system would be equally complex in the end. Now I remember, my unit LazUnicode in LazUtils has classes: - TCodePointEnumerator and - TUnicodeCharacterEnumerator which can handle Combining Diacritical Marks. It may be enough for most European + many other languages. Please take a look. Maybe you could use the idea for a new abstract "character" class. Anyway such a complex logic must be in library code, not in compiler's built-in type. Or maybe you just want fixed-width indexing of codepoints without dealing with complexities of Unicode. In that case UTF-32 and a new string type UTF32String or similar would do it. Juha From mschnell at lumino.de Fri Aug 18 13:02:44 2017 From: mschnell at lumino.de (Michael Schnell) Date: Fri, 18 Aug 2017 13:02:44 +0200 Subject: [Lazarus] String vs WideString In-Reply-To: References: <1ivuocdrq736eamemh6mp6h9old5omrssn@4ax.com> <38b0193a-eb86-4d6a-6292-f2203daff126@mccallumwhyman.com> <20170814154654.52d5d1d4@limapholos.matflo.wg> <08ed778e-1db6-c2d6-2c55-c21fdee67272@mccallumwhyman.com> <827d76a0-1344-91a6-dab6-06d17665fc2f@lumino.de> Message-ID: <50a13752-eab8-d6c5-4002-56a01e50721e@lumino.de> On 18.08.2017 11:01, Graeme Geldenhuys via Lazarus wrote: > On 2017-08-18 09:16, Tony Whyman via Lazarus wrote: >> Damn, should remember never to copy and paste from Wikipedia! > > Or simply use "plain text" emails To explain my mail above in plain Text: A 32 bit Unicode needs two UTC-16 codes when it's greater than 2^15 (and not 2^16) , because bit 15 in UTF-16 is used to denote that another word follows. -Michael From mailinglists at geldenhuys.co.uk Fri Aug 18 13:17:24 2017 From: mailinglists at geldenhuys.co.uk (Graeme Geldenhuys) Date: Fri, 18 Aug 2017 12:17:24 +0100 Subject: [Lazarus] String vs WideString In-Reply-To: <50a13752-eab8-d6c5-4002-56a01e50721e@lumino.de> References: <1ivuocdrq736eamemh6mp6h9old5omrssn@4ax.com> <38b0193a-eb86-4d6a-6292-f2203daff126@mccallumwhyman.com> <20170814154654.52d5d1d4@limapholos.matflo.wg> <08ed778e-1db6-c2d6-2c55-c21fdee67272@mccallumwhyman.com> <827d76a0-1344-91a6-dab6-06d17665fc2f@lumino.de> <50a13752-eab8-d6c5-4002-56a01e50721e@lumino.de> Message-ID: <48d217ea-4169-a253-3c33-80cbae160f01@geldenhuys.co.uk> On 2017-08-18 12:02, Michael Schnell wrote: > To explain my mail above in plain Text: Nice. :-) And clever email clients will even "format" the plain text emails - looking much better than your original HTML version. See attached screenshot of how your last email looked like here. 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: shot1.png Type: image/png Size: 3606 bytes Desc: not available URL: From mse00000 at gmail.com Fri Aug 18 13:45:39 2017 From: mse00000 at gmail.com (Martin Schreiber) Date: Fri, 18 Aug 2017 13:45:39 +0200 Subject: [Lazarus] String vs WideString In-Reply-To: <50a13752-eab8-d6c5-4002-56a01e50721e@lumino.de> References: <50a13752-eab8-d6c5-4002-56a01e50721e@lumino.de> Message-ID: <201708181345.39733.mse00000@gmail.com> On Friday 18 August 2017 13:02:44 Michael Schnell via Lazarus wrote: > On 18.08.2017 11:01, Graeme Geldenhuys via Lazarus wrote: > > On 2017-08-18 09:16, Tony Whyman via Lazarus wrote: > >> Damn, should remember never to copy and paste from Wikipedia! > > > > Or simply use "plain text" emails > > To explain my mail above in plain Text: > > A 32 bit Unicode needs two UTC-16 codes when it's greater than 2^15 (and > not 2^16) , because bit 15 in UTF-16 is used to denote that another word > follows. > Not exactly. ;-) Please read the utf-16 specification again. The surrogate pair first code unit range is 0xDC00..0xDFFF. The rest can be used to encode code points of the BMP. There are no valid code points in range 0xDC00..0xDFFF. https://en.wikipedia.org/wiki/UTF-16 Martin From pascaldragon at googlemail.com Fri Aug 18 14:26:51 2017 From: pascaldragon at googlemail.com (Sven Barth) Date: Fri, 18 Aug 2017 14:26:51 +0200 Subject: [Lazarus] String vs WideString In-Reply-To: References: <20170814154654.52d5d1d4@limapholos.matflo.wg> <20170815111313.0d368eaf@limapholos.matflo.wg> <3956bacd-2902-ea33-060b-252de9f97ca5@geldenhuys.co.uk> <66aa5516-1c29-f48e-1337-13abd8413e8d@wetron.es> <624223a6-e1ff-0006-0134-2777ffda4bc8@geldenhuys.co.uk> <9d7ba4a1-7382-cbbb-0897-6f8d8fe386ce@lumino.de> Message-ID: Am 18.08.2017 10:42 schrieb "Michael Schnell via Lazarus" < lazarus at lists.lazarus-ide.org>: > > On 17.08.2017 11:27, Sven Barth via Lazarus wrote: >> >> >> Why do you want to stuff everything and the kitchen sink into TStrings? >> > To make use of the benefits the string type offers such as reference counting and lazy copy. The same is true for dynamic arrays. So again the question where is the need for TStrings? And don't come along with the String operations like Delete(), Insert() and Pos() again, because those aren't covered by TStrings either. Regards, Sven -------------- next part -------------- An HTML attachment was scrubbed... URL: From mschnell at lumino.de Fri Aug 18 14:51:33 2017 From: mschnell at lumino.de (Michael Schnell) Date: Fri, 18 Aug 2017 14:51:33 +0200 Subject: [Lazarus] String vs WideString In-Reply-To: References: <20170815111313.0d368eaf@limapholos.matflo.wg> <3956bacd-2902-ea33-060b-252de9f97ca5@geldenhuys.co.uk> <66aa5516-1c29-f48e-1337-13abd8413e8d@wetron.es> <624223a6-e1ff-0006-0134-2777ffda4bc8@geldenhuys.co.uk> <9d7ba4a1-7382-cbbb-0897-6f8d8fe386ce@lumino.de> Message-ID: On 18.08.2017 14:26, Sven Barth via Lazarus wrote: > Delete(), Insert() and Pos() I understand those, and "+", etc, are in the pipe for Array of Byte, as well. I suppose workalikes for the most important TStrings siblings, such as TStringlist (including sort and LoadFromFile) be doable on top of that. Might be good news for new programs. Legacy stuff will need to be ported appropriately (as already discussed here). -Michael From lazarus at kluug.net Fri Aug 18 22:44:06 2017 From: lazarus at kluug.net (Ondrej Pokorny) Date: Fri, 18 Aug 2017 22:44:06 +0200 Subject: [Lazarus] String vs WideString In-Reply-To: References: <38b0193a-eb86-4d6a-6292-f2203daff126@mccallumwhyman.com> <20170814154654.52d5d1d4@limapholos.matflo.wg> <20170815111313.0d368eaf@limapholos.matflo.wg> <3956bacd-2902-ea33-060b-252de9f97ca5@geldenhuys.co.uk> <66aa5516-1c29-f48e-1337-13abd8413e8d@wetron.es> <624223a6-e1ff-0006-0134-2777ffda4bc8@geldenhuys.co.uk> Message-ID: <701a3a3a-f2c1-10f8-504a-cfaa1776beb1@kluug.net> On 16.08.2017 22:40, Sven Barth via Lazarus wrote: > Trunk supports Insert() and Delete() on dynamic arrays, Concat() and + > are on the near term ToDo list. I eagerly wait for these (and for anonymous methods) :) Ondrej From friess at gmx.at Sat Aug 19 22:14:08 2017 From: friess at gmx.at (=?UTF-8?Q?Andreas_Frie=c3=9f?=) Date: Sat, 19 Aug 2017 22:14:08 +0200 Subject: [Lazarus] Reporting engine - What it's state? In-Reply-To: References: <559EC1C4.80108@yahoo.com> <30250fa8-3d84-e335-40e7-c36ace7638c7@gmx.at> Message-ID: .... and the week goes by :-) Any news about the report-engine ? Or had i miss this in the (fpc) trunk ? Andreas Am 12.08.2017 um 11:03 schrieb Michael Van Canneyt via Lazarus: > > Hi, > > I will commit the code to FPC svn the coming week. > > Michael. > > On Fri, 11 Aug 2017, Andreas Frieß via Lazarus wrote: > >> Hi, >> >> pls, where can the actual 'unstable ?' Code found ? fpc trunk, where ? >> >> Thanks >> Andreas >> >> Am 24.07.2017 um 08:54 schrieb Michael Van Canneyt via Lazarus: >>> >>> >>> On Mon, 24 Jul 2017, Gabor Boros via Lazarus wrote: >>> >>>> Hi All, >>>> >>>> 2015. 07. 09. 21:45 keltezéssel, Michael Van Canneyt írta: >>>>> Just an opinion: >>>>> I am working with Graeme Geldenhuys to create a reporting engine >>>>> from scratch. >>>>> I think Lazreport's design contains some fundamental flaws, which >>>>> can only be remedied by re-implementing a reporting engine from >>>>> scratch. >>>> >>>> Two years gone. Any news? I see "In progress" on the Foundation's >>>> page, but want to know more detailed informations. >>>> >>>> https://foundation.freepascal.org/projects/reporting-engine >>> >>> It's ready and waiting for release. I'm waiting for 2 small fixes >>> still: >>> - Some strange error when exporting a custom element to PDF >>> - Removing a dependency on freetype.dll on windows. >>> >>> Michael. >>> >>> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at freepascal.org Sat Aug 19 22:41:45 2017 From: michael at freepascal.org (Michael Van Canneyt) Date: Sat, 19 Aug 2017 22:41:45 +0200 (CEST) Subject: [Lazarus] Reporting engine - What it's state? In-Reply-To: References: <559EC1C4.80108@yahoo.com> <30250fa8-3d84-e335-40e7-c36ace7638c7@gmx.at> Message-ID: On Sat, 19 Aug 2017, Andreas Frieß via Lazarus wrote: > .... and the week goes by :-) It's not yet over. > > Any news about the report-engine ? Or had i miss this in the (fpc) trunk ? No, it is planned for tomorrow. I have other things on my plate as well :) Michael. From prindex2010 at gmail.com Sun Aug 20 14:16:59 2017 From: prindex2010 at gmail.com (Tudor Hulban) Date: Sun, 20 Aug 2017 15:16:59 +0300 Subject: [Lazarus] Reporting engine - What it's state? In-Reply-To: References: <559EC1C4.80108@yahoo.com> <30250fa8-3d84-e335-40e7-c36ace7638c7@gmx.at> Message-ID: hi, maybe the code could be released with these two bugs? at least the community could see the code and start assessing the scenarios in which the code could be used. and also given the code maybe somebody can help with the fixes. thank you, tudor hulban On 8/19/17, Andreas Frieß via Lazarus wrote: > .... and the week goes by :-) > > Any news about the report-engine ? Or had i miss this in the (fpc) trunk ? > > Andreas > > > Am 12.08.2017 um 11:03 schrieb Michael Van Canneyt via Lazarus: >> >> Hi, >> >> I will commit the code to FPC svn the coming week. >> >> Michael. >> >> On Fri, 11 Aug 2017, Andreas Frieß via Lazarus wrote: >> >>> Hi, >>> >>> pls, where can the actual 'unstable ?' Code found ? fpc trunk, where ? >>> >>> Thanks >>> Andreas >>> >>> Am 24.07.2017 um 08:54 schrieb Michael Van Canneyt via Lazarus: >>>> >>>> >>>> On Mon, 24 Jul 2017, Gabor Boros via Lazarus wrote: >>>> >>>>> Hi All, >>>>> >>>>> 2015. 07. 09. 21:45 keltezéssel, Michael Van Canneyt írta: >>>>>> Just an opinion: >>>>>> I am working with Graeme Geldenhuys to create a reporting engine >>>>>> from scratch. >>>>>> I think Lazreport's design contains some fundamental flaws, which >>>>>> can only be remedied by re-implementing a reporting engine from >>>>>> scratch. >>>>> >>>>> Two years gone. Any news? I see "In progress" on the Foundation's >>>>> page, but want to know more detailed informations. >>>>> >>>>> https://foundation.freepascal.org/projects/reporting-engine >>>> >>>> It's ready and waiting for release. I'm waiting for 2 small fixes >>>> still: >>>> - Some strange error when exporting a custom element to PDF >>>> - Removing a dependency on freetype.dll on windows. >>>> >>>> Michael. >>>> >>>> >>> >>> >> >> > > From md at delfire.net Sun Aug 20 18:55:09 2017 From: md at delfire.net (Marcos Douglas B. Santos) Date: Sun, 20 Aug 2017 13:55:09 -0300 Subject: [Lazarus] Namespace In-Reply-To: <4D2DF8B5.3000708@googlemail.com> References: <4D2A04CB.4000700@aol.com> <4D2AFEFB.4060200@aol.com> <4D2CC5A5.6070401@aol.com> <475337849.20110112175734@gmx.de> <1782546404.56284.1294853070352.JavaMail.open-xchange@cc-app3.netcologne.de> <4D2DF8B5.3000708@googlemail.com> Message-ID: On Wed, Jan 12, 2011 at 3:53 PM, Sven Barth wrote: > On 12.01.2011 18:24, Mattias Gaertner wrote: >> >> Marcos Douglas hat am 12. Januar 2011 um 18:05 >> geschrieben: >> >> > On Wed, Jan 12, 2011 at 1:57 PM, Andreas Schneider >> wrote: >> > > >> > > ... which you can already do. The unit order in the uses clause >> > > already determines which identifier is chosen when you do *not* >> > > specify a unit explicitly. So just make sure that LCL's TButton is >> > > always the default one and you can still use your own TButton by >> > > prefixing it with your own unitname. All you want is already there >> and >> > > seems to cover 99% of the usecases. >> > >> > But I can register a component called TButton? >> >> No, that would conflict with the LCL TButton. See the FCL function >> FindClass. > > > If I see that right, then even if Lazarus would implement this it would need > a new FPC release with an extended FindClass to enable this. As the current > release is just two months old this might not happen in just some weeks. Hi Sven. Do you have any news about it? Best regards, Marcos Douglas From pascaldragon at googlemail.com Sun Aug 20 19:26:19 2017 From: pascaldragon at googlemail.com (Sven Barth) Date: Sun, 20 Aug 2017 19:26:19 +0200 Subject: [Lazarus] Namespace In-Reply-To: References: <4D2A04CB.4000700@aol.com> <4D2AFEFB.4060200@aol.com> <4D2CC5A5.6070401@aol.com> <475337849.20110112175734@gmx.de> <1782546404.56284.1294853070352.JavaMail.open-xchange@cc-app3.netcologne.de> <4D2DF8B5.3000708@googlemail.com> Message-ID: Am 20.08.2017 18:55 schrieb "Marcos Douglas B. Santos via Lazarus" < lazarus at lists.lazarus-ide.org>: > > On Wed, Jan 12, 2011 at 3:53 PM, Sven Barth wrote: > > On 12.01.2011 18:24, Mattias Gaertner wrote: > >> > >> Marcos Douglas hat am 12. Januar 2011 um 18:05 > >> geschrieben: > >> > >> > On Wed, Jan 12, 2011 at 1:57 PM, Andreas Schneider > >> wrote: > >> > > > >> > > ... which you can already do. The unit order in the uses clause > >> > > already determines which identifier is chosen when you do *not* > >> > > specify a unit explicitly. So just make sure that LCL's TButton is > >> > > always the default one and you can still use your own TButton by > >> > > prefixing it with your own unitname. All you want is already there > >> and > >> > > seems to cover 99% of the usecases. > >> > > >> > But I can register a component called TButton? > >> > >> No, that would conflict with the LCL TButton. See the FCL function > >> FindClass. > > > > > > If I see that right, then even if Lazarus would implement this it would need > > a new FPC release with an extended FindClass to enable this. As the current > > release is just two months old this might not happen in just some weeks. > > Hi Sven. > Do you have any news about it? Why should I have any news? I merely stated what would need to happen if this is to be changed. Regards, Sven -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at freepascal.org Sun Aug 20 20:35:19 2017 From: michael at freepascal.org (Michael Van Canneyt) Date: Sun, 20 Aug 2017 20:35:19 +0200 (CEST) Subject: [Lazarus] fpReport released Message-ID: Hello, A long time wait. But it finally made it: fpreport has been committed to FPC SVN: packages/fcl-report. It should compile on windows, linux, freebsd and darwin. Features and architecture are described on: http://wiki.freepascal.org/FPReport Short highlights: - Banded report design. - Streaming to JSON, streaming XML is on TODO. - Expressions using fpexprpars. - No GUI Dependencies. - Unit tested. - Standard support for Memo (with HTML tags embedded), image, shape and checkbox elements - Data loop for Dataset, JSON data, collections, lists, event driven. - Framework for extending with other elements (demo contains polygon). - Export out of the box to following format: - Pure HTML. (TOC pages, optional use of frames, highly configurable) - Images (with option to generate HTML container pages. Currently requires FreeType on windows) - PDF (using fcl-pdf) There are 11 demo reports in a command-line. There is also a standalone webdemo with the same demos, which shows that fpreport can be used very easily in a headless webserver. The LCL support has been committed to lazarus: components/fpreport. It contains: - Preview (export to LCL canvas) - Printing. - Design-time support for a report. - Stand-alone designer, with support for accessing data from: CSV, DBF, SQLDB, JSON File, any REST service that exports JSON. Allows preview and export to all known formats. - LCL demo program. Todo: - XML - Remove freetype dependency. - subreport. - crosstab. - chart support. Exporters for FPGUI and AggPas are also available, I expect that Graeme Geldenhuys will commit them soon. Please remember, this is a first release. There are some known bugs and shortcomings. Feel free to report anything you find in the bugtracker, suggestions are also welcome. Enjoy, Michael. [5~ From md at delfire.net Sun Aug 20 20:42:35 2017 From: md at delfire.net (Marcos Douglas B. Santos) Date: Sun, 20 Aug 2017 15:42:35 -0300 Subject: [Lazarus] Namespace In-Reply-To: References: <4D2A04CB.4000700@aol.com> <4D2AFEFB.4060200@aol.com> <4D2CC5A5.6070401@aol.com> <475337849.20110112175734@gmx.de> <1782546404.56284.1294853070352.JavaMail.open-xchange@cc-app3.netcologne.de> <4D2DF8B5.3000708@googlemail.com> Message-ID: On Sun, Aug 20, 2017 at 2:26 PM, Sven Barth via Lazarus wrote: > Am 20.08.2017 18:55 schrieb "Marcos Douglas B. Santos via Lazarus" > : >> >> On Wed, Jan 12, 2011 at 3:53 PM, Sven Barth >> wrote: >> > On 12.01.2011 18:24, Mattias Gaertner wrote: >> >> >> >> Marcos Douglas hat am 12. Januar 2011 um 18:05 >> >> geschrieben: >> >> >> >> > On Wed, Jan 12, 2011 at 1:57 PM, Andreas Schneider >> >> wrote: >> >> > > >> >> > > ... which you can already do. The unit order in the uses clause >> >> > > already determines which identifier is chosen when you do *not* >> >> > > specify a unit explicitly. So just make sure that LCL's TButton is >> >> > > always the default one and you can still use your own TButton by >> >> > > prefixing it with your own unitname. All you want is already there >> >> and >> >> > > seems to cover 99% of the usecases. >> >> > >> >> > But I can register a component called TButton? >> >> >> >> No, that would conflict with the LCL TButton. See the FCL function >> >> FindClass. >> > >> > >> > If I see that right, then even if Lazarus would implement this it would >> > need >> > a new FPC release with an extended FindClass to enable this. As the >> > current >> > release is just two months old this might not happen in just some weeks. >> >> Hi Sven. >> Do you have any news about it? > > Why should I have any news? I merely stated what would need to happen if > this is to be changed. It was just a question... never mind. Thanks. Best regards, Marcos Douglas From m-w-vogel at gmx.de Sun Aug 20 21:05:04 2017 From: m-w-vogel at gmx.de (Michael W. Vogel) Date: Sun, 20 Aug 2017 21:05:04 +0200 Subject: [Lazarus] fpReport released In-Reply-To: References: Message-ID: <0dc86af7-4fab-3ce8-f6c1-3efda1ab1948@gmx.de> Am 20.08.2017 um 20:35 schrieb Michael Van Canneyt via Lazarus: > fpreport has been committed to FPC SVN: packages/fcl-report. > It should compile on windows, linux, freebsd and darwin. I just tried to compile a clean fpc: make distclean make all install INSTALL_PREFIX=%FpcPath% PP=%BootStrapCompilerPath%\ppc386.exe I got this error: Start compiling package fcl-report for target i386-win32. Compiling fcl-report\BuildUnit_fcl_report.pp Compiling .\fcl-report\src\fpreportstreamer.pp Compiling .\fcl-report\src\fpreporthtmlparser.pp Compiling .\fcl-report\src\fpreport.pp Compiling .\fcl-report\src\fpjsonreport.pp Compiling .\fcl-report\src\fpreportjson.pp Compiling .\fcl-report\src\fpreportdb.pp External command "c:/32fpc311/fpc/compiler/ppc386.exe -Twin32 -FUfcl-report\unit s\i386-win32\ -Fuc:\32fpc311\fpc\rtl\units\i386-win32\ -Fuc:\32fpc311\fpc\packag es\fcl-base\units\i386-win32\ -Fuc:\32fpc311\fpc\packages\fcl-res\units\i386-win 32\ -Fuc:\32fpc311\fpc\packages\rtl-objpas\units\i386-win32\ -Fuc:\32fpc311\fpc\ packages\fcl-image\units\i386-win32\ -Fuc:\32fpc311\fpc\packages\pasjpeg\units\i 386-win32\ -Fuc:\32fpc311\fpc\packages\paszlib\units\i386-win32\ -Fuc:\32fpc311\ fpc\packages\hash\units\i386-win32\ -Fuc:\32fpc311\fpc\packages\fcl-xml\units\i3 86-win32\ -Fuc:\32fpc311\fpc\packages\fcl-pdf\units\i386-win32\ -Fuc:\32fpc311\f pc\packages\fcl-json\units\i386-win32\ -Fufcl-report\src -Ur -Xs -O2 -n -di386 - dRELEASE -XX -CX -viq fcl-report\BuildUnit_fcl_report.pp" failed with exit code 1. Console output: Target OS: Win32 for i386 Compiling fcl-report\BuildUnit_fcl_report.pp Compiling .\fcl-report\src\fpreportstreamer.pp Writing Resource String Table file: fpreportstreamer.rsj Compiling .\fcl-report\src\fpreporthtmlparser.pp Compiling .\fcl-report\src\fpreport.pp Writing Resource String Table file: fpreport.rsj Compiling .\fcl-report\src\fpjsonreport.pp Writing Resource String Table file: fpjsonreport.rsj Compiling .\fcl-report\src\fpreportjson.pp Writing Resource String Table file: fpreportjson.rsj Compiling .\fcl-report\src\fpreportdb.pp fpreportdb.pp(22,32) Fatal: Can't find unit db used by fpreportdb Fatal: Compilation aborted The installer encountered the following error: Compilation of "BuildUnit_fcl_report.pp" failed make[2]: *** [smart] Error 1 make[2]: Leaving directory `c:/32fpc311/fpc/packages' make[1]: *** [packages_smart] Error 2 make[1]: Leaving directory `c:/32fpc311/fpc' make: *** [build-stamp.i386-win32] Error 2 Michl From michael at freepascal.org Sun Aug 20 21:16:02 2017 From: michael at freepascal.org (Michael Van Canneyt) Date: Sun, 20 Aug 2017 21:16:02 +0200 (CEST) Subject: [Lazarus] fpReport released In-Reply-To: <0dc86af7-4fab-3ce8-f6c1-3efda1ab1948@gmx.de> References: <0dc86af7-4fab-3ce8-f6c1-3efda1ab1948@gmx.de> Message-ID: On Sun, 20 Aug 2017, Michael W. Vogel via Lazarus wrote: > Am 20.08.2017 um 20:35 schrieb Michael Van Canneyt via Lazarus: >> fpreport has been committed to FPC SVN: packages/fcl-report. >> It should compile on windows, linux, freebsd and darwin. > > I just tried to compile a clean fpc: > fpreportdb.pp(22,32) Fatal: Can't find unit db used by fpreportdb > Fatal: Compilation aborted Missing dependency. I added it, please update and try again. No idea why this always happens to me. I do a "make clean all" and it just works :/ Michael. From m-w-vogel at gmx.de Sun Aug 20 21:25:34 2017 From: m-w-vogel at gmx.de (Michael W. Vogel) Date: Sun, 20 Aug 2017 21:25:34 +0200 Subject: [Lazarus] fpReport released In-Reply-To: References: <0dc86af7-4fab-3ce8-f6c1-3efda1ab1948@gmx.de> Message-ID: Am 20.08.2017 um 21:16 schrieb Michael Van Canneyt via Lazarus: > Missing dependency. I added it, please update and try again. It's compiled now. Thank you very much! Let's test your report :) Michl From mailinglists at geldenhuys.co.uk Sun Aug 20 21:35:19 2017 From: mailinglists at geldenhuys.co.uk (Graeme Geldenhuys) Date: Sun, 20 Aug 2017 20:35:19 +0100 Subject: [Lazarus] Reporting engine - What it's state? In-Reply-To: References: <559EC1C4.80108@yahoo.com> <30250fa8-3d84-e335-40e7-c36ace7638c7@gmx.at> Message-ID: <3a3433ac-b75e-acb0-cd83-12c0afe4a557@geldenhuys.co.uk> On 2017-08-20 13:16, Tudor Hulban via Lazarus wrote: > and also given the code maybe somebody can help with the fixes. I've already found the cause of the problem exporting custom elements to PDF. Not many will hit the error anyway, either way I'll correctly implement a fix tomorrow and post a patch to Mantis. 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 From mailinglists at geldenhuys.co.uk Sun Aug 20 21:36:56 2017 From: mailinglists at geldenhuys.co.uk (Graeme Geldenhuys) Date: Sun, 20 Aug 2017 20:36:56 +0100 Subject: [Lazarus] Reporting engine - What it's state? In-Reply-To: References: <559EC1C4.80108@yahoo.com> <30250fa8-3d84-e335-40e7-c36ace7638c7@gmx.at> Message-ID: <66b07a57-8005-177b-a87b-ff165f2445d6@geldenhuys.co.uk> On 2017-08-20 13:16, Tudor Hulban via Lazarus wrote: > maybe the code could be released with these two bugs? ps: In case you didn't see the announcement, the fpReport code was released today. 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 From friess at gmx.at Sun Aug 20 22:05:07 2017 From: friess at gmx.at (=?UTF-8?Q?Andreas_Frie=c3=9f?=) Date: Sun, 20 Aug 2017 22:05:07 +0200 Subject: [Lazarus] fpReport released In-Reply-To: References: <0dc86af7-4fab-3ce8-f6c1-3efda1ab1948@gmx.de> Message-ID: Thx Michael & Graeme for the fcl-report. But is there a fcl-report package for Lazarus, because the web-demo asked me for ? Or should be an extra package for Lazarus planned ? Andreas Am 20.08.2017 um 21:16 schrieb Michael Van Canneyt via Lazarus: > > > On Sun, 20 Aug 2017, Michael W. Vogel via Lazarus wrote: > >> Am 20.08.2017 um 20:35 schrieb Michael Van Canneyt via Lazarus: >>> fpreport has been committed to FPC SVN: packages/fcl-report. >>> It should compile on windows, linux, freebsd and darwin. >> >> I just tried to compile a clean fpc: >> fpreportdb.pp(22,32) Fatal: Can't find unit db used by fpreportdb >> Fatal: Compilation aborted > > Missing dependency. I added it, please update and try again. > > No idea why this always happens to me. I do a "make clean all" and it > just works :/ > > Michael. From mailinglists at geldenhuys.co.uk Sun Aug 20 22:12:38 2017 From: mailinglists at geldenhuys.co.uk (Graeme Geldenhuys) Date: Sun, 20 Aug 2017 21:12:38 +0100 Subject: [Lazarus] fpReport released In-Reply-To: References: <0dc86af7-4fab-3ce8-f6c1-3efda1ab1948@gmx.de> Message-ID: <5b2dceb9-a28a-0fac-4307-1a41931c6305@geldenhuys.co.uk> On 2017-08-20 21:05, Andreas Frieß via Lazarus wrote: > But is there a fcl-report package for Lazarus, because the web-demo > asked me for ? Or should be an extra package for Lazarus planned ? There definitely was a fclfpreport.lpk package and the demo had a dependency on that. This was when everything was in a single reporting repository though. Maybe because of the repository split (FPC, Lazarus and fpGUI) things got lost along the way. I'll have to get a Lazarus repo update to double check what Michael committed in there. 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 From friess at gmx.at Sun Aug 20 22:16:03 2017 From: friess at gmx.at (=?UTF-8?Q?Andreas_Frie=c3=9f?=) Date: Sun, 20 Aug 2017 22:16:03 +0200 Subject: [Lazarus] fpReport released In-Reply-To: References: <0dc86af7-4fab-3ce8-f6c1-3efda1ab1948@gmx.de> Message-ID: <3776a32a-74e7-5df0-04f7-40f22ea9fd56@gmx.at> If i want to start the demo in windows, some dll's are missing. The freetype dll searched by the fpreport was freetype-6.dll, but the actual freetype-2.3.5-1-bin.zip has only a freetype6.dll. (Renaming is not a problem for me) Source: http://gnuwin32.sourceforge.net/packages/freetype.htm (Binaries only) Andreas From friess at gmx.at Sun Aug 20 22:32:30 2017 From: friess at gmx.at (=?UTF-8?Q?Andreas_Frie=c3=9f?=) Date: Sun, 20 Aug 2017 22:32:30 +0200 Subject: [Lazarus] fpReport released In-Reply-To: <5b2dceb9-a28a-0fac-4307-1a41931c6305@geldenhuys.co.uk> References: <0dc86af7-4fab-3ce8-f6c1-3efda1ab1948@gmx.de> <5b2dceb9-a28a-0fac-4307-1a41931c6305@geldenhuys.co.uk> Message-ID: <55d3a22e-551d-2e62-94b1-3f8dacbd0c19@gmx.at> Thx Graeme, i some changes in the Lazarus trunk now too. I didnt reconiced this on Lazarus, because i'm actually on the 1.8RC path :-) But i can backport this :-) Sorry for my noise. Andreas Am 20.08.2017 um 22:12 schrieb Graeme Geldenhuys via Lazarus: > On 2017-08-20 21:05, Andreas Frieß via Lazarus wrote: >> But is there a fcl-report package for Lazarus, because the web-demo >> asked me for ? Or should be an extra package for Lazarus planned ? > > There definitely was a fclfpreport.lpk package and the demo had a > dependency on that. This was when everything was in a single reporting > repository though. Maybe because of the repository split (FPC, Lazarus > and fpGUI) things got lost along the way. I'll have to get a Lazarus > repo update to double check what Michael committed in there. > > Regards, > Graeme > From noreply at z505.com Sun Aug 20 23:21:46 2017 From: noreply at z505.com (noreply at z505.com) Date: Sun, 20 Aug 2017 16:21:46 -0500 Subject: [Lazarus] The new kid is growing up fast In-Reply-To: <9f46c1f8-c4b1-846b-601b-e86e898bdac2@geldenhuys.co.uk> References: <9f46c1f8-c4b1-846b-601b-e86e898bdac2@geldenhuys.co.uk> Message-ID: On 2017-08-15 06:19, Graeme Geldenhuys via Lazarus wrote: > Hi guys, > > Just wanted to show you guys something. The new kid on the block is > growing up very fast.... CrossVCL. > > https://www.youtube.com/watch?v=_lr_BQlXvkk > > I believe the programmer is the ex-FMX (FireMonkey) developer that was > let go by Embarcadero, and he is hitting back with a vengeance. The > CrossVCL project has grown from nothing to something in an extremely > short time. Coming from a toolkit designer myself, that is very > impressive to see. > > > Regards, > Graeme Is there some technical info page "how it works"? Does it require WINE or anything obscure, which makes installing apps difficult for the end user? It says Win API, so as soon as I heard that I thought "WINE" but I have no idea :-) From noreply at z505.com Sun Aug 20 23:50:12 2017 From: noreply at z505.com (noreply at z505.com) Date: Sun, 20 Aug 2017 16:50:12 -0500 Subject: [Lazarus] The new kid is growing up fast In-Reply-To: <154ee5ce-15be-bd71-5a6d-87d6efad70a0@geldenhuys.co.uk> References: <9f46c1f8-c4b1-846b-601b-e86e898bdac2@geldenhuys.co.uk> <6b24c127-5799-04bf-3537-2b919c37bfb5@lumino.de> <154ee5ce-15be-bd71-5a6d-87d6efad70a0@geldenhuys.co.uk> Message-ID: <37a3f38f8938ba0decac7cf152c21838@z505.com> On 2017-08-15 14:16, Graeme Geldenhuys via Lazarus wrote: > On 2017-08-15 12:35, Michael Schnell via Lazarus wrote: >> How to compare it against Lazarus ? > > No idea - I've only been watching the CrossVCL videos as milestones > get reached. I've never tried CrossVCL personally, and don't use > Delphi personally either (since 2006). > Didn't you pull delphi out recently for some work you said? Anyway, I'd like to know more technical details of how CrossVCL actually works... compared to how lazarus works. Lazarus compiles native apps for each platform, whereas CrossVCL? May make the same mistakes as Kylix? Or not. If anyone wants, this could be changed to Fpc-Other post, sorry if it's not on topic for Lazarus discussions. It could be related in that the architecture behind crossvcl could be studied for research and ideas could be used between it, but.. From mailinglists at geldenhuys.co.uk Mon Aug 21 01:38:16 2017 From: mailinglists at geldenhuys.co.uk (Graeme Geldenhuys) Date: Mon, 21 Aug 2017 00:38:16 +0100 Subject: [Lazarus] fpReport released In-Reply-To: <3776a32a-74e7-5df0-04f7-40f22ea9fd56@gmx.at> References: <0dc86af7-4fab-3ce8-f6c1-3efda1ab1948@gmx.de> <3776a32a-74e7-5df0-04f7-40f22ea9fd56@gmx.at> Message-ID: <900c7837-d9ed-e469-0991-316ff1a9a0e3@geldenhuys.co.uk> On 2017-08-20 21:16, Andreas Frieß via Lazarus wrote: > The freetype dll searched by the fpreport was freetype-6.dll, but the > actual freetype-2.3.5-1-bin.zip has only a freetype6.dll. (Renaming is > not a problem for me) It seems FreeType has some inconsistencies with its releases and naming of the DLL. I have copies of freetype-6.dll, freetype6.dll and freetype.dll - all version 6 and all downloaded from somewhere on the Internet. I guess the one good thing is that there is a fpReport TODO item to remove the freetype*.dll dependencies for Windows in the future. That is already possible with the AggPas exporter, but in that specific case I prefer the freetype usage as it generates better text via AggPas and has more features that the Windows Font API supports. 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 From mailinglists at geldenhuys.co.uk Mon Aug 21 01:44:46 2017 From: mailinglists at geldenhuys.co.uk (Graeme Geldenhuys) Date: Mon, 21 Aug 2017 00:44:46 +0100 Subject: [Lazarus] The new kid is growing up fast In-Reply-To: <37a3f38f8938ba0decac7cf152c21838@z505.com> References: <9f46c1f8-c4b1-846b-601b-e86e898bdac2@geldenhuys.co.uk> <6b24c127-5799-04bf-3537-2b919c37bfb5@lumino.de> <154ee5ce-15be-bd71-5a6d-87d6efad70a0@geldenhuys.co.uk> <37a3f38f8938ba0decac7cf152c21838@z505.com> Message-ID: <4f80c609-1680-83bc-d573-bf702b7a3839@geldenhuys.co.uk> On 2017-08-20 22:50, Lars via Lazarus wrote: > Didn't you pull delphi out recently for some work you said? I meant I don't use Delphi in my own company or for personal projects. But if I do contracting work for a client that already uses Delphi, then of course I need to use Delphi too (until I can convince them to move to Free Pascal ). 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 From mailinglists at geldenhuys.co.uk Mon Aug 21 01:54:56 2017 From: mailinglists at geldenhuys.co.uk (Graeme Geldenhuys) Date: Mon, 21 Aug 2017 00:54:56 +0100 Subject: [Lazarus] The new kid is growing up fast In-Reply-To: References: <9f46c1f8-c4b1-846b-601b-e86e898bdac2@geldenhuys.co.uk> Message-ID: <12da1b26-17d0-4ca6-b6af-ce0c1a47fb67@geldenhuys.co.uk> On 2017-08-20 22:21, Lars via Lazarus wrote: > Does it require WINE or anything obscure, which makes installing apps > difficult for the end user? It doesn't use WINE as far as I know. As I understand it, it is similar to LCL in that the toolkit API implementation is very Windows API centric (obviously because VCL is). So they have implemented a "bridge" where Windows API calls are translated to native API's, no matter the platform - similar to what WINE does, but not actually using WINE. There FAQ page explains in much better and in more detail: http://www.crossvcl.com/faq.html My issue with CrossVCL is that it requires Delphi 10.2 and the OSX add-on for Mac targets, or the Enterprise edition of Delphi to target Linux. That means a considerable expense! FPC and Lazarus is FREE and targets the same platforms or more. And personally I doubt I'll ever move back to closed source development tools. 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 From michael at freepascal.org Mon Aug 21 08:35:51 2017 From: michael at freepascal.org (Michael Van Canneyt) Date: Mon, 21 Aug 2017 08:35:51 +0200 (CEST) Subject: [Lazarus] fpReport released In-Reply-To: References: <0dc86af7-4fab-3ce8-f6c1-3efda1ab1948@gmx.de> Message-ID: On Sun, 20 Aug 2017, Andreas Frieß via Lazarus wrote: > Thx Michael & Graeme for the fcl-report. > > But is there a fcl-report package for Lazarus, because the web-demo > asked me for ? Or should be an extra package for Lazarus planned ? This is an old package from when the sources were in a separate repo. It is no longer needed. I removed the dependency. BTW. All code should definitely compile with 3.0.2 or later, and if you collect all sources that make up the various parts, the core engine and exporters should work even with 2.6.4. Michael. From friess at gmx.at Mon Aug 21 08:57:34 2017 From: friess at gmx.at (=?UTF-8?Q?Andreas_Frie=c3=9f?=) Date: Mon, 21 Aug 2017 08:57:34 +0200 Subject: [Lazarus] fpReport released In-Reply-To: <900c7837-d9ed-e469-0991-316ff1a9a0e3@geldenhuys.co.uk> References: <0dc86af7-4fab-3ce8-f6c1-3efda1ab1948@gmx.de> <3776a32a-74e7-5df0-04f7-40f22ea9fd56@gmx.at> <900c7837-d9ed-e469-0991-316ff1a9a0e3@geldenhuys.co.uk> Message-ID: <1a310d4d-ade4-aecc-cc9e-1f7c07314a45@gmx.at> I'm on Win10 Pro/64 1703. The needed fonts are not found by the program, because they are not in my system (%windir%/fonts). In fpTTF only the WinDir is added to the searchlist. So an Exception is raised and the execution of the lcldemo stops here. The fonts are in the fcl-report/demos/fonts. Regards Andreas Am 21.08.2017 um 01:38 schrieb Graeme Geldenhuys via Lazarus: > On 2017-08-20 21:16, Andreas Frieß via Lazarus wrote: >> The freetype dll searched by the fpreport was freetype-6.dll, but the >> actual freetype-2.3.5-1-bin.zip has only a freetype6.dll. (Renaming is >> not a problem for me) > > It seems FreeType has some inconsistencies with its releases and > naming of the DLL. I have copies of freetype-6.dll, freetype6.dll and > freetype.dll - all version 6 and all downloaded from somewhere on the > Internet. > > I guess the one good thing is that there is a fpReport TODO item to > remove the freetype*.dll dependencies for Windows in the future. That > is already possible with the AggPas exporter, but in that specific > case I prefer the freetype usage as it generates better text via > AggPas and has more features that the Windows Font API supports. > > Regards, > Graeme > From michael at freepascal.org Mon Aug 21 08:59:54 2017 From: michael at freepascal.org (Michael Van Canneyt) Date: Mon, 21 Aug 2017 08:59:54 +0200 (CEST) Subject: [Lazarus] fpReport released In-Reply-To: <1a310d4d-ade4-aecc-cc9e-1f7c07314a45@gmx.at> References: <0dc86af7-4fab-3ce8-f6c1-3efda1ab1948@gmx.de> <3776a32a-74e7-5df0-04f7-40f22ea9fd56@gmx.at> <900c7837-d9ed-e469-0991-316ff1a9a0e3@geldenhuys.co.uk> <1a310d4d-ade4-aecc-cc9e-1f7c07314a45@gmx.at> Message-ID: On Mon, 21 Aug 2017, Andreas Frieß via Lazarus wrote: > I'm on Win10 Pro/64 1703. The needed fonts are not found by the program, > because they are not in my system (%windir%/fonts). In fpTTF only the > WinDir is added to the searchlist. So an Exception is raised and the > execution of the lcldemo stops here. The fonts are in the > fcl-report/demos/fonts. The demos are normally adding the current dir+fonts to the search path. udapp line 241. Michael. From lazarus at kluug.net Mon Aug 21 09:08:07 2017 From: lazarus at kluug.net (Ondrej Pokorny) Date: Mon, 21 Aug 2017 09:08:07 +0200 Subject: [Lazarus] fpReport released In-Reply-To: <900c7837-d9ed-e469-0991-316ff1a9a0e3@geldenhuys.co.uk> References: <0dc86af7-4fab-3ce8-f6c1-3efda1ab1948@gmx.de> <3776a32a-74e7-5df0-04f7-40f22ea9fd56@gmx.at> <900c7837-d9ed-e469-0991-316ff1a9a0e3@geldenhuys.co.uk> Message-ID: On 21.08.2017 1:38, Graeme Geldenhuys via Lazarus wrote: > On 2017-08-20 21:16, Andreas Frieß via Lazarus wrote: >> The freetype dll searched by the fpreport was freetype-6.dll, but the >> actual freetype-2.3.5-1-bin.zip has only a freetype6.dll. (Renaming is >> not a problem for me) > > It seems FreeType has some inconsistencies with its releases and > naming of the DLL. I have copies of freetype-6.dll, freetype6.dll and > freetype.dll - all version 6 and all downloaded from somewhere on the > Internet. > > I guess the one good thing is that there is a fpReport TODO item to > remove the freetype*.dll dependencies for Windows in the future. That > is already possible with the AggPas exporter, but in that specific > case I prefer the freetype usage as it generates better text via > AggPas and has more features that the Windows Font API supports. I use my own reporting engine - very similar to fpReport (no GUI dependency, no DB dependency, XML-template based). I use fpTTF for getting font information for rendering. Can't you use it as well? For LCL bitmap output (preview), I use EasyLazFreeType / TIntfFreeTypeDrawer directly to get a TLazIntfImage. No need for AggPas or other libraries. What do you need freetype for? Ondrej From michael at freepascal.org Mon Aug 21 09:11:52 2017 From: michael at freepascal.org (Michael Van Canneyt) Date: Mon, 21 Aug 2017 09:11:52 +0200 (CEST) Subject: [Lazarus] fpReport released In-Reply-To: References: <0dc86af7-4fab-3ce8-f6c1-3efda1ab1948@gmx.de> <3776a32a-74e7-5df0-04f7-40f22ea9fd56@gmx.at> <900c7837-d9ed-e469-0991-316ff1a9a0e3@geldenhuys.co.uk> Message-ID: On Mon, 21 Aug 2017, Ondrej Pokorny via Lazarus wrote: > On 21.08.2017 1:38, Graeme Geldenhuys via Lazarus wrote: >> On 2017-08-20 21:16, Andreas Frieß via Lazarus wrote: >>> The freetype dll searched by the fpreport was freetype-6.dll, but the >>> actual freetype-2.3.5-1-bin.zip has only a freetype6.dll. (Renaming is >>> not a problem for me) >> >> It seems FreeType has some inconsistencies with its releases and >> naming of the DLL. I have copies of freetype-6.dll, freetype6.dll and >> freetype.dll - all version 6 and all downloaded from somewhere on the >> Internet. >> >> I guess the one good thing is that there is a fpReport TODO item to >> remove the freetype*.dll dependencies for Windows in the future. That >> is already possible with the AggPas exporter, but in that specific >> case I prefer the freetype usage as it generates better text via >> AggPas and has more features that the Windows Font API supports. > > I use my own reporting engine - very similar to fpReport (no GUI > dependency, no DB dependency, XML-template based). I use fpTTF for > getting font information for rendering. Can't you use it as well? It is already used. > > For LCL bitmap output (preview), I use EasyLazFreeType / > TIntfFreeTypeDrawer directly to get a TLazIntfImage. No need for AggPas > or other libraries. Only if you use the LCL. > > What do you need freetype for? If you use the HTML or PDF rendering, you don't need it. If you want fpImage rendering, it is needed to actually render text. I'm working on having this dependency on freetype removed. Michael. From friess at gmx.at Mon Aug 21 09:56:05 2017 From: friess at gmx.at (=?UTF-8?Q?Andreas_Frie=c3=9f?=) Date: Mon, 21 Aug 2017 09:56:05 +0200 Subject: [Lazarus] fpReport released In-Reply-To: References: <0dc86af7-4fab-3ce8-f6c1-3efda1ab1948@gmx.de> <3776a32a-74e7-5df0-04f7-40f22ea9fd56@gmx.at> <900c7837-d9ed-e469-0991-316ff1a9a0e3@geldenhuys.co.uk> <1a310d4d-ade4-aecc-cc9e-1f7c07314a45@gmx.at> Message-ID: <83ac7619-49a7-db33-7616-b729b8dc82d7@gmx.at> Thanks, its true for the app in fpc directory. So i have to look for the Lazarus Demos/Designer too. Andreas Am 21.08.2017 um 08:59 schrieb Michael Van Canneyt via Lazarus: > > > On Mon, 21 Aug 2017, Andreas Frieß via Lazarus wrote: > >> I'm on Win10 Pro/64 1703. The needed fonts are not found by the >> program, because they are not in my system (%windir%/fonts). In >> fpTTF only the WinDir is added to the searchlist. So an Exception is >> raised and the execution of the lcldemo stops here. The fonts are in >> the fcl-report/demos/fonts. > > The demos are normally adding the current dir+fonts to the search path. > udapp line 241. > > Michael. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mailinglists at geldenhuys.co.uk Mon Aug 21 09:59:55 2017 From: mailinglists at geldenhuys.co.uk (Graeme Geldenhuys) Date: Mon, 21 Aug 2017 08:59:55 +0100 Subject: [Lazarus] fpReport released In-Reply-To: References: <0dc86af7-4fab-3ce8-f6c1-3efda1ab1948@gmx.de> <3776a32a-74e7-5df0-04f7-40f22ea9fd56@gmx.at> <900c7837-d9ed-e469-0991-316ff1a9a0e3@geldenhuys.co.uk> Message-ID: On 2017-08-21 08:08, Ondrej Pokorny via Lazarus wrote: > For LCL bitmap output (preview), I use EasyLazFreeType Michael explained it all in his reply. I would just like to add that the above EasyLazFreeType unit (if I remember correctly) is based on a very old Pascal implementation of FreeType v1. There are a ton of FreeType features not supported by that unit. 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 From mailinglists at geldenhuys.co.uk Mon Aug 21 10:01:46 2017 From: mailinglists at geldenhuys.co.uk (Graeme Geldenhuys) Date: Mon, 21 Aug 2017 09:01:46 +0100 Subject: [Lazarus] fpReport released In-Reply-To: References: <0dc86af7-4fab-3ce8-f6c1-3efda1ab1948@gmx.de> Message-ID: <8a487c5d-ce22-d996-018b-b6bb5b31145c@geldenhuys.co.uk> On 2017-08-21 07:35, Michael Van Canneyt via Lazarus wrote: > and if you collect all sources that make up the various parts, > the core engine and exporters should work even with 2.6.4. Last I tested, that definitely worked too. Regards, Graeme From andrea.mauri.75 at gmail.com Mon Aug 21 10:06:23 2017 From: andrea.mauri.75 at gmail.com (Andrea Mauri) Date: Mon, 21 Aug 2017 10:06:23 +0200 Subject: [Lazarus] childsizing homogeneous macosx Message-ID: Dear all, I noticed that on macosx childiszing is working strangely. If I use homogeneus child resize the controls are not homogeneously resized. See attached image. Andrea -------------- next part -------------- A non-text attachment was scrubbed... Name: childsizing_osx.jpg Type: image/jpeg Size: 64088 bytes Desc: not available URL: From friess at gmx.at Mon Aug 21 10:09:46 2017 From: friess at gmx.at (=?UTF-8?Q?Andreas_Frie=c3=9f?=) Date: Mon, 21 Aug 2017 10:09:46 +0200 Subject: [Lazarus] fpReport -> Lazarus reportdsg.lpr Message-ID: <7fc26a43-f02a-d88e-b6a0-d030ec73f4c3@gmx.at> I think there ara som issues with the fonts. frmreportdesignermain.pp around line 395 if gTTFontCache.SearchPath.Count=0 then begin {$IFDEF UNIX} gTTFontCache.SearchPath.Add(ExtractFilePath(ParamStr(0))+'../demos/fonts/'); gTTFontCache.SearchPath.Add(GetUserDir + '.fonts/'); gTTFontCache.SearchPath.Add('/usr/share/fonts/truetype/ubuntu-font-family/'); gTTFontCache.SearchPath.Add('/usr/share/fonts/truetype/dejavu/'); {$ENDIF} end; if (gTTFontCache.Count=0) then gTTFontCache.BuildFontCache; // calls directly to fpTTF in fpTTF procedure TFPFontCacheList.BuildFontCache; var lPath: String; i: integer; begin if FSearchPath.Count < 1 then raise ETTF.Create(rsNoSearchPathDefined); // here is the exception raised I think in windows is no searchpath definded by default. The lines in should: because its also true for windows. if gTTFontCache.SearchPath.Count=0 then begin gTTFontCache.SearchPath.Add(ExtractFilePath(ParamStr(0))+'../demos/fonts/'); gTTFontCache.SearchPath.Add(GetUserDir + '.fonts/'); {$IFDEF UNIX} gTTFontCache.SearchPath.Add('/usr/share/fonts/truetype/ubuntu-font-family/'); gTTFontCache.SearchPath.Add('/usr/share/fonts/truetype/dejavu/'); {$ENDIF} end; --------------------------------- If i say create a new report, another issue is, the DPI settings in Ruler are not initialised or set. So you get un runtimeerror here procedure TDrawRuler.RecalcParams; var I:Integer; begin FPPU:=PixelsPerUnit(DPI,FUnits); // DPI is zero FMajorTicks:=(DPI/FPPU); //<- FFPPU is zero -> divison by zero! I:=Trunc(FMajorTicks); case I of Fix: constructor TDrawRuler.Create(ACanvas: TCanvas); begin FCanvas:=ACanvas; FFont:=TFont.Create; Color:=clWhite; FTickColor:=cldkGray; FType:=rtTop; FUnits:=ruCm; FZeroOffset:=0; FDPI:=96; //<--- should be an basic value RecalcParams; end; Andreas -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at freepascal.org Mon Aug 21 10:18:43 2017 From: michael at freepascal.org (Michael Van Canneyt) Date: Mon, 21 Aug 2017 10:18:43 +0200 (CEST) Subject: [Lazarus] fpReport -> Lazarus reportdsg.lpr In-Reply-To: <7fc26a43-f02a-d88e-b6a0-d030ec73f4c3@gmx.at> References: <7fc26a43-f02a-d88e-b6a0-d030ec73f4c3@gmx.at> Message-ID: On Mon, 21 Aug 2017, Andreas Frieß via Lazarus wrote: > I think there ara som issues with the fonts. > > frmreportdesignermain.pp around line 395 > > if gTTFontCache.SearchPath.Count=0 then > begin > {$IFDEF UNIX} > gTTFontCache.SearchPath.Add(ExtractFilePath(ParamStr(0))+'../demos/fonts/'); > gTTFontCache.SearchPath.Add(GetUserDir + '.fonts/'); > gTTFontCache.SearchPath.Add('/usr/share/fonts/truetype/ubuntu-font-family/'); > gTTFontCache.SearchPath.Add('/usr/share/fonts/truetype/dejavu/'); > {$ENDIF} > end; > if (gTTFontCache.Count=0) then > gTTFontCache.BuildFontCache; // calls directly to fpTTF > > in fpTTF > > procedure TFPFontCacheList.BuildFontCache; > var > lPath: String; > i: integer; > begin > if FSearchPath.Count < 1 then > raise ETTF.Create(rsNoSearchPathDefined); // here is the exception > raised > > I think in windows is no searchpath definded by default. The lines in should: > because its also true for windows. > > if gTTFontCache.SearchPath.Count=0 then > begin > gTTFontCache.SearchPath.Add(ExtractFilePath(ParamStr(0))+'../demos/fonts/'); > gTTFontCache.SearchPath.Add(GetUserDir + '.fonts/'); > {$IFDEF UNIX} > gTTFontCache.SearchPath.Add('/usr/share/fonts/truetype/ubuntu-font-family/'); > gTTFontCache.SearchPath.Add('/usr/share/fonts/truetype/dejavu/'); > {$ENDIF} > end; > > --------------------------------- I will look at this. The '../demos/fonts' and other hardcoded values are maybe not really a good idea :) > > If i say create a new report, another issue is, the DPI settings in Ruler are > not initialised or set. So you get un runtimeerror here > > procedure TDrawRuler.RecalcParams; > var I:Integer; > begin > FPPU:=PixelsPerUnit(DPI,FUnits); // DPI is zero > FMajorTicks:=(DPI/FPPU); //<- FFPPU is zero -> divison by > zero! > I:=Trunc(FMajorTicks); > case I of > > Fix: > > constructor TDrawRuler.Create(ACanvas: TCanvas); > begin > FCanvas:=ACanvas; > FFont:=TFont.Create; > Color:=clWhite; > FTickColor:=cldkGray; > FType:=rtTop; > FUnits:=ruCm; > FZeroOffset:=0; > FDPI:=96; //<--- should be an basic value > RecalcParams; > end; VERY strange, I never had this error. I patched the code. Michael. From nc-gaertnma at netcologne.de Mon Aug 21 10:19:13 2017 From: nc-gaertnma at netcologne.de (Mattias Gaertner) Date: Mon, 21 Aug 2017 10:19:13 +0200 Subject: [Lazarus] childsizing homogeneous macosx In-Reply-To: References: Message-ID: <20170821101913.43e92f8e@limapholos.matflo.wg> On Mon, 21 Aug 2017 10:06:23 +0200 Andrea Mauri via Lazarus wrote: > Dear all, > > I noticed that on macosx childiszing is working strangely. > If I use homogeneus child resize the controls are not homogeneously resized. > See attached image. Please create a bug report. Mattias From andrea.mauri.75 at gmail.com Mon Aug 21 10:34:41 2017 From: andrea.mauri.75 at gmail.com (Andrea Mauri) Date: Mon, 21 Aug 2017 10:34:41 +0200 Subject: [Lazarus] childsizing homogeneous macosx In-Reply-To: <20170821101913.43e92f8e@limapholos.matflo.wg> References: <20170821101913.43e92f8e@limapholos.matflo.wg> Message-ID: <864098df-e232-b88b-f200-e8bd59dc17f9@gmail.com> done bugid 0032307 Il 21/08/2017 10:19, Mattias Gaertner via Lazarus ha scritto: > On Mon, 21 Aug 2017 10:06:23 +0200 > Andrea Mauri via Lazarus wrote: > >> Dear all, >> >> I noticed that on macosx childiszing is working strangely. >> If I use homogeneus child resize the controls are not homogeneously resized. >> See attached image. > > Please create a bug report. > > Mattias > From mailinglists at geldenhuys.co.uk Mon Aug 21 10:50:21 2017 From: mailinglists at geldenhuys.co.uk (Graeme Geldenhuys) Date: Mon, 21 Aug 2017 09:50:21 +0100 Subject: [Lazarus] fpReport -> Lazarus reportdsg.lpr In-Reply-To: References: <7fc26a43-f02a-d88e-b6a0-d030ec73f4c3@gmx.at> Message-ID: <2361e1aa-71d8-e04e-551e-ad0d127dcf5b@geldenhuys.co.uk> On 2017-08-21 09:18, Michael Van Canneyt via Lazarus wrote: > The '../demos/fonts' and other hardcoded values are maybe not really > a good idea:) For the life of me, I couldn't think of another solution. eg: you might have a headless reporting CGI app and needs to look for fonts in a specific location, not the general "fonts" directories of the system. But yes, the hard-coded paths like.... gTTFontCache.SearchPath.Add('/usr/share/fonts/truetype/....'); isn't ideal. Especially if you consider the inconsistency between Linux distros, and the fact that FreeBSD uses /usr/local/share/fonts/ instead of /usr/share/fonts/ But again, unless we extend the IFDEFs for most used OSes, I couldn't think of a better solution. What if we introduce a global (or user-defined) ~/.config/fpreport/fpreport.ini file that specifies default font search paths for our specific reporting needs - per system? But then again, isn't that what the standardised $HOME/.fonts/ is for? Sorry, just thinking out loudly. ;-) 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 From michael at freepascal.org Mon Aug 21 10:54:22 2017 From: michael at freepascal.org (Michael Van Canneyt) Date: Mon, 21 Aug 2017 10:54:22 +0200 (CEST) Subject: [Lazarus] fpReport -> Lazarus reportdsg.lpr In-Reply-To: <2361e1aa-71d8-e04e-551e-ad0d127dcf5b@geldenhuys.co.uk> References: <7fc26a43-f02a-d88e-b6a0-d030ec73f4c3@gmx.at> <2361e1aa-71d8-e04e-551e-ad0d127dcf5b@geldenhuys.co.uk> Message-ID: On Mon, 21 Aug 2017, Graeme Geldenhuys via Lazarus wrote: > On 2017-08-21 09:18, Michael Van Canneyt via Lazarus wrote: >> The '../demos/fonts' and other hardcoded values are maybe not really >> a good idea:) > > For the life of me, I couldn't think of another solution. eg: you might > have a headless reporting CGI app and needs to look for fonts in a > specific location, not the general "fonts" directories of the system. > > But yes, the hard-coded paths like.... > > gTTFontCache.SearchPath.Add('/usr/share/fonts/truetype/....'); > > isn't ideal. Especially if you consider the inconsistency between Linux > distros, and the fact that FreeBSD uses /usr/local/share/fonts/ instead > of /usr/share/fonts/ > > But again, unless we extend the IFDEFs for most used OSes, I couldn't > think of a better solution. > > What if we introduce a global (or user-defined) > ~/.config/fpreport/fpreport.ini file that specifies default font search > paths for our specific reporting needs - per system? But then again, > isn't that what the standardised $HOME/.fonts/ is for? These problems will only occur if you're using non-standard fonts. If you recall, I wanted to analyse /etc/fonts/fonts.conf on unix. (not sure if that is used on FreeBSD) On windows, normally only the windows fonts dir should be needed. Michael. From mailinglists at geldenhuys.co.uk Mon Aug 21 11:11:34 2017 From: mailinglists at geldenhuys.co.uk (Graeme Geldenhuys) Date: Mon, 21 Aug 2017 10:11:34 +0100 Subject: [Lazarus] fpReport -> Lazarus reportdsg.lpr In-Reply-To: References: <7fc26a43-f02a-d88e-b6a0-d030ec73f4c3@gmx.at> <2361e1aa-71d8-e04e-551e-ad0d127dcf5b@geldenhuys.co.uk> Message-ID: <994f192a-298e-3a89-747c-b1272014c6c3@geldenhuys.co.uk> On 2017-08-21 09:54, Michael Van Canneyt via Lazarus wrote: > These problems will only occur if you're using non-standard fonts. What if you wanted "self contained reports" eg like the demos in fpReport where we use fonts that are not available on all systems. eg: Windows doesn't come standard with DejaVu. Other Linux distros and FreeBSD doesn't come standard with the Ubuntu font. > If you recall, I wanted to analyse /etc/fonts/fonts.conf on unix. > (not sure if that is used on FreeBSD) Yes, FreeBSD uses that too, but again, it is located in the user-installed apps location... /usr/local/etc/fonts/ Looking at that file here (again, not sure how Linux distro compare or differ), but there are .... tags in the beginning of the fonts.conf file. Simply adding those to fpTTF's search path should already go a long way. That should be pretty easy to add. /usr/local/share/fonts /usr/local/lib/X11/fonts fonts ~/.fonts 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 From michael at freepascal.org Mon Aug 21 11:18:06 2017 From: michael at freepascal.org (Michael Van Canneyt) Date: Mon, 21 Aug 2017 11:18:06 +0200 (CEST) Subject: [Lazarus] fpReport -> Lazarus reportdsg.lpr In-Reply-To: <994f192a-298e-3a89-747c-b1272014c6c3@geldenhuys.co.uk> References: <7fc26a43-f02a-d88e-b6a0-d030ec73f4c3@gmx.at> <2361e1aa-71d8-e04e-551e-ad0d127dcf5b@geldenhuys.co.uk> <994f192a-298e-3a89-747c-b1272014c6c3@geldenhuys.co.uk> Message-ID: On Mon, 21 Aug 2017, Graeme Geldenhuys via Lazarus wrote: > On 2017-08-21 09:54, Michael Van Canneyt via Lazarus wrote: >> These problems will only occur if you're using non-standard fonts. > > What if you wanted "self contained reports" eg like the demos in > fpReport where we use fonts that are not available on all systems. eg: > Windows doesn't come standard with DejaVu. Other Linux distros and > FreeBSD doesn't come standard with the Ubuntu font. Then you need to add Location+'fonts/' or so, and distribute the font. If the font isn't there, you can't use it, clearly :) An idea would be to have aliases for substitution. >> If you recall, I wanted to analyse /etc/fonts/fonts.conf on unix. >> (not sure if that is used on FreeBSD) > > Yes, FreeBSD uses that too, but again, it is located in the > user-installed apps location... /usr/local/etc/fonts/ > > Looking at that file here (again, not sure how Linux distro compare or > differ), but there are .... tags in the beginning of the > fonts.conf file. Simply adding those to fpTTF's search path should > already go a long way. That should be pretty easy to add. > > > > /usr/local/share/fonts > /usr/local/lib/X11/fonts > fonts > > ~/.fonts Should indeed be easy to parse and handle... Michael. From mailinglists at geldenhuys.co.uk Mon Aug 21 11:25:01 2017 From: mailinglists at geldenhuys.co.uk (Graeme Geldenhuys) Date: Mon, 21 Aug 2017 10:25:01 +0100 Subject: [Lazarus] fpReport -> Lazarus reportdsg.lpr In-Reply-To: References: <7fc26a43-f02a-d88e-b6a0-d030ec73f4c3@gmx.at> <2361e1aa-71d8-e04e-551e-ad0d127dcf5b@geldenhuys.co.uk> <994f192a-298e-3a89-747c-b1272014c6c3@geldenhuys.co.uk> Message-ID: <888ae36d-ed68-9c40-9fe1-c49e0fff9ce3@geldenhuys.co.uk> On 2017-08-21 10:18, Michael Van Canneyt wrote: >> >> >> /usr/local/share/fonts >> /usr/local/lib/X11/fonts >> fonts >> >> ~/.fonts > Should indeed be easy to parse and handle... I'll make it so. I guess the best option would be to add it as an option API call, so if somebody wants it, simply call .AddStandardFontPaths(). For those that don't want those font paths, simply do nothing. 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 From friess at gmx.at Mon Aug 21 11:35:45 2017 From: friess at gmx.at (=?UTF-8?Q?Andreas_Frie=c3=9f?=) Date: Mon, 21 Aug 2017 11:35:45 +0200 Subject: [Lazarus] fpReport -> Lazarus reportdsg.lpr In-Reply-To: <888ae36d-ed68-9c40-9fe1-c49e0fff9ce3@geldenhuys.co.uk> References: <7fc26a43-f02a-d88e-b6a0-d030ec73f4c3@gmx.at> <2361e1aa-71d8-e04e-551e-ad0d127dcf5b@geldenhuys.co.uk> <994f192a-298e-3a89-747c-b1272014c6c3@geldenhuys.co.uk> <888ae36d-ed68-9c40-9fe1-c49e0fff9ce3@geldenhuys.co.uk> Message-ID: It is possible to use a standard font and give a warning instead of fire an exception. Eg. Font xxxx not found, using standardfont instead .... ? Andreas Am 21.08.2017 um 11:25 schrieb Graeme Geldenhuys via Lazarus: > On 2017-08-21 10:18, Michael Van Canneyt wrote: >>> >>> >>> /usr/local/share/fonts >>> /usr/local/lib/X11/fonts >>> fonts >>> >>> ~/.fonts >> Should indeed be easy to parse and handle... > > I'll make it so. I guess the best option would be to add it as an > option API call, so if somebody wants it, simply call > .AddStandardFontPaths(). For those that don't want those font > paths, simply do nothing. > > Regards, > Graeme > From michael at freepascal.org Mon Aug 21 11:47:26 2017 From: michael at freepascal.org (Michael Van Canneyt) Date: Mon, 21 Aug 2017 11:47:26 +0200 (CEST) Subject: [Lazarus] fpReport -> Lazarus reportdsg.lpr In-Reply-To: References: <7fc26a43-f02a-d88e-b6a0-d030ec73f4c3@gmx.at> <2361e1aa-71d8-e04e-551e-ad0d127dcf5b@geldenhuys.co.uk> <994f192a-298e-3a89-747c-b1272014c6c3@geldenhuys.co.uk> <888ae36d-ed68-9c40-9fe1-c49e0fff9ce3@geldenhuys.co.uk> Message-ID: On Mon, 21 Aug 2017, Andreas Frieß via Lazarus wrote: > It is possible to use a standard font and give a warning instead of fire > an exception. > > Eg. Font xxxx not found, using standardfont instead .... ? That is what I meant with introducing aliases. The problem is of course that you normally do not want this in a reporting engine, where the looks are important. So using aliases should be an option... Michael. From mailinglists at geldenhuys.co.uk Mon Aug 21 11:49:52 2017 From: mailinglists at geldenhuys.co.uk (Graeme Geldenhuys) Date: Mon, 21 Aug 2017 10:49:52 +0100 Subject: [Lazarus] fpReport -> Lazarus reportdsg.lpr In-Reply-To: References: <7fc26a43-f02a-d88e-b6a0-d030ec73f4c3@gmx.at> <2361e1aa-71d8-e04e-551e-ad0d127dcf5b@geldenhuys.co.uk> <994f192a-298e-3a89-747c-b1272014c6c3@geldenhuys.co.uk> <888ae36d-ed68-9c40-9fe1-c49e0fff9ce3@geldenhuys.co.uk> Message-ID: On 2017-08-21 10:35, Andreas Frieß via Lazarus wrote: > It is possible to use a standard font and give a warning instead of fire > an exception. > > Eg. Font xxxx not found, using standardfont instead .... ? I don't like that. First, how are you going to display the warning? Remember fpReport was designed to be able to run from console or headless servers too, not just desktop apps. Secondly, how are you going to substitute the font? Which font will you choose, and how will you make that choice? Using equivalent font metrics values, simply by name, some random standard font that might make your report look crap? My personal opinion - I like to see a report the way I designed it or not at all (until I fixed what was missing or broken). 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 From mailinglists at geldenhuys.co.uk Mon Aug 21 11:51:38 2017 From: mailinglists at geldenhuys.co.uk (Graeme Geldenhuys) Date: Mon, 21 Aug 2017 10:51:38 +0100 Subject: [Lazarus] fpReport -> Lazarus reportdsg.lpr In-Reply-To: References: <7fc26a43-f02a-d88e-b6a0-d030ec73f4c3@gmx.at> <2361e1aa-71d8-e04e-551e-ad0d127dcf5b@geldenhuys.co.uk> <994f192a-298e-3a89-747c-b1272014c6c3@geldenhuys.co.uk> <888ae36d-ed68-9c40-9fe1-c49e0fff9ce3@geldenhuys.co.uk> Message-ID: <8ed83ca5-86db-5410-53f1-21510998ccbf@geldenhuys.co.uk> On 2017-08-21 10:47, Michael Van Canneyt via Lazarus wrote: > The problem is of course that you normally do not want this in a reporting > engine, where the looks are important. Exactly! Some reports could be very dependent on a specific font and font metrics for the layout (internal to fpReport and simply about looks). Regards, Graeme From friess at gmx.at Mon Aug 21 11:58:20 2017 From: friess at gmx.at (=?UTF-8?Q?Andreas_Frie=c3=9f?=) Date: Mon, 21 Aug 2017 11:58:20 +0200 Subject: [Lazarus] fpReport -> Lazarus reportdsg.lpr In-Reply-To: References: <7fc26a43-f02a-d88e-b6a0-d030ec73f4c3@gmx.at> <2361e1aa-71d8-e04e-551e-ad0d127dcf5b@geldenhuys.co.uk> <994f192a-298e-3a89-747c-b1272014c6c3@geldenhuys.co.uk> <888ae36d-ed68-9c40-9fe1-c49e0fff9ce3@geldenhuys.co.uk> Message-ID: At first this should for the visual part (Designer eg.) And should for windows this not added ? Because in windows the fonts should reside in %windir%\Fonts (see MS documentation) function GetWinDirFonts: string; var dir: array [0..MAX_PATH] of Char; begin GetWindowsDirectory(dir, MAX_PATH); Result := StrPas(dir)+DirectorySeparator+'Fonts'; end; and {$ifdef mswindows} SearchPath.Add(GetWinDir); SearchPath.Add(GetWinDirFonts); {$endif} in fpttf.pp around line 560 Andreas Am 21.08.2017 um 11:49 schrieb Graeme Geldenhuys via Lazarus: > On 2017-08-21 10:35, Andreas Frieß via Lazarus wrote: >> It is possible to use a standard font and give a warning instead of fire >> an exception. >> >> Eg. Font xxxx not found, using standardfont instead .... ? > > I don't like that. First, how are you going to display the warning? > Remember fpReport was designed to be able to run from console or > headless servers too, not just desktop apps. Secondly, how are you > going to substitute the font? Which font will you choose, and how will > you make that choice? Using equivalent font metrics values, simply by > name, some random standard font that might make your report look crap? > My personal opinion - I like to see a report the way I designed it or > not at all (until I fixed what was missing or broken). > > Regards, > Graeme > From pascaldragon at googlemail.com Mon Aug 21 13:49:18 2017 From: pascaldragon at googlemail.com (Sven Barth) Date: Mon, 21 Aug 2017 13:49:18 +0200 Subject: [Lazarus] fpReport -> Lazarus reportdsg.lpr In-Reply-To: <888ae36d-ed68-9c40-9fe1-c49e0fff9ce3@geldenhuys.co.uk> References: <7fc26a43-f02a-d88e-b6a0-d030ec73f4c3@gmx.at> <2361e1aa-71d8-e04e-551e-ad0d127dcf5b@geldenhuys.co.uk> <994f192a-298e-3a89-747c-b1272014c6c3@geldenhuys.co.uk> <888ae36d-ed68-9c40-9fe1-c49e0fff9ce3@geldenhuys.co.uk> Message-ID: Am 21.08.2017 11:25 schrieb "Graeme Geldenhuys via Lazarus" < lazarus at lists.lazarus-ide.org>: > > On 2017-08-21 10:18, Michael Van Canneyt wrote: >>> >>> >>> >>> /usr/local/share/fonts >>> /usr/local/lib/X11/fonts >>> fonts >>> >>> ~/.fonts >> >> Should indeed be easy to parse and handle... > > > I'll make it so. I guess the best option would be to add it as an option API call, so if somebody wants it, simply call .AddStandardFontPaths(). For those that don't want those font paths, simply do nothing. Why not dynamically load the fontconfig library and ask that instead of manually parsing its config file? Note: fontconfig doesn't have GUI dependencies either. Regards, Sven -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at freepascal.org Mon Aug 21 13:56:18 2017 From: michael at freepascal.org (Michael Van Canneyt) Date: Mon, 21 Aug 2017 13:56:18 +0200 (CEST) Subject: [Lazarus] fpReport -> Lazarus reportdsg.lpr In-Reply-To: References: <7fc26a43-f02a-d88e-b6a0-d030ec73f4c3@gmx.at> <2361e1aa-71d8-e04e-551e-ad0d127dcf5b@geldenhuys.co.uk> <994f192a-298e-3a89-747c-b1272014c6c3@geldenhuys.co.uk> <888ae36d-ed68-9c40-9fe1-c49e0fff9ce3@geldenhuys.co.uk> Message-ID: On Mon, 21 Aug 2017, Sven Barth via Lazarus wrote: > Am 21.08.2017 11:25 schrieb "Graeme Geldenhuys via Lazarus" < > lazarus at lists.lazarus-ide.org>: >> >> On 2017-08-21 10:18, Michael Van Canneyt wrote: >>>> >>>> >>>> >>>> /usr/local/share/fonts >>>> /usr/local/lib/X11/fonts >>>> fonts >>>> >>>> ~/.fonts >>> >>> Should indeed be easy to parse and handle... >> >> >> I'll make it so. I guess the best option would be to add it as an option > API call, so if somebody wants it, simply call > .AddStandardFontPaths(). For those that don't want those font paths, > simply do nothing. > > Why not dynamically load the fontconfig library and ask that instead of > manually parsing its config file? Because I didn't know such a library existed :) > Note: fontconfig doesn't have GUI dependencies either. Well, in that case we can try to load it dynamically if it is available, and fall back to parsing if it is not. Many thanks for the tip !! Michael. From friess at gmx.at Mon Aug 21 14:00:19 2017 From: friess at gmx.at (=?UTF-8?Q?Andreas_Frie=c3=9f?=) Date: Mon, 21 Aug 2017 14:00:19 +0200 Subject: [Lazarus] fpReport -> Lazarus reportdsg.lpr In-Reply-To: References: <7fc26a43-f02a-d88e-b6a0-d030ec73f4c3@gmx.at> <2361e1aa-71d8-e04e-551e-ad0d127dcf5b@geldenhuys.co.uk> <994f192a-298e-3a89-747c-b1272014c6c3@geldenhuys.co.uk> <888ae36d-ed68-9c40-9fe1-c49e0fff9ce3@geldenhuys.co.uk> Message-ID: Is is not better to call the standard fonts of the system in TFPReportDesignerForm.FormCreate(Sender: TObject); ? if gTTFontCache.SearchPath.Count=0 then begin gTTFontCache.SearchPath.Add(ExtractFilePath(ParamStr(0))+'../demos/fonts/'); gTTFontCache.SearchPath.Add(GetUserDir + '.fonts/'); {$IFDEF UNIX} gTTFontCache.SearchPath.Add('/usr/share/fonts/truetype/ubuntu-font-family/'); gTTFontCache.SearchPath.Add('/usr/share/fonts/truetype/dejavu/'); {$ENDIF} end; if (gTTFontCache.Count=0) then gTTFontCache.BuildFontCache; if (gTTFontCache.Count=0) then // <------- gTTFontCache.ReadStandardFonts; // <------- Because the standardfonts are not read in the designer. Andreas Am 21.08.2017 um 11:58 schrieb Andreas Frieß via Lazarus: > At first this should for the visual part (Designer eg.) > > And should for windows this not added ? Because in windows the fonts > should reside in %windir%\Fonts (see MS documentation) > > function GetWinDirFonts: string; > var > dir: array [0..MAX_PATH] of Char; > begin > GetWindowsDirectory(dir, MAX_PATH); > Result := StrPas(dir)+DirectorySeparator+'Fonts'; > end; > > and > > {$ifdef mswindows} > SearchPath.Add(GetWinDir); > SearchPath.Add(GetWinDirFonts); > {$endif} > > in fpttf.pp around line 560 > > Andreas > > Am 21.08.2017 um 11:49 schrieb Graeme Geldenhuys via Lazarus: >> On 2017-08-21 10:35, Andreas Frieß via Lazarus wrote: >>> It is possible to use a standard font and give a warning instead of >>> fire >>> an exception. >>> >>> Eg. Font xxxx not found, using standardfont instead .... ? >> >> I don't like that. First, how are you going to display the warning? >> Remember fpReport was designed to be able to run from console or >> headless servers too, not just desktop apps. Secondly, how are you >> going to substitute the font? Which font will you choose, and how >> will you make that choice? Using equivalent font metrics values, >> simply by name, some random standard font that might make your report >> look crap? My personal opinion - I like to see a report the way I >> designed it or not at all (until I fixed what was missing or broken). >> >> Regards, >> Graeme >> > From michael at freepascal.org Mon Aug 21 14:03:03 2017 From: michael at freepascal.org (Michael Van Canneyt) Date: Mon, 21 Aug 2017 14:03:03 +0200 (CEST) Subject: [Lazarus] fpReport -> Lazarus reportdsg.lpr In-Reply-To: References: <7fc26a43-f02a-d88e-b6a0-d030ec73f4c3@gmx.at> <2361e1aa-71d8-e04e-551e-ad0d127dcf5b@geldenhuys.co.uk> <994f192a-298e-3a89-747c-b1272014c6c3@geldenhuys.co.uk> <888ae36d-ed68-9c40-9fe1-c49e0fff9ce3@geldenhuys.co.uk> Message-ID: On Mon, 21 Aug 2017, Andreas Frieß via Lazarus wrote: > Is is not better to call the standard fonts of the system in > TFPReportDesignerForm.FormCreate(Sender: TObject); ? > > if gTTFontCache.SearchPath.Count=0 then > begin > gTTFontCache.SearchPath.Add(ExtractFilePath(ParamStr(0))+'../demos/fonts/'); > gTTFontCache.SearchPath.Add(GetUserDir + '.fonts/'); > {$IFDEF UNIX} > gTTFontCache.SearchPath.Add('/usr/share/fonts/truetype/ubuntu-font-family/'); > gTTFontCache.SearchPath.Add('/usr/share/fonts/truetype/dejavu/'); > {$ENDIF} > end; > if (gTTFontCache.Count=0) then > gTTFontCache.BuildFontCache; > if (gTTFontCache.Count=0) then // <------- > gTTFontCache.ReadStandardFonts; // <------- > > Because the standardfonts are not read in the designer. Yes. A patch for this was already provided by Pascal Riekenberg. It has been applied. Michael. From wkitty42 at windstream.net Mon Aug 21 16:29:17 2017 From: wkitty42 at windstream.net (wkitty42 at windstream.net) Date: Mon, 21 Aug 2017 10:29:17 -0400 Subject: [Lazarus] fpReport -> Lazarus reportdsg.lpr In-Reply-To: References: <7fc26a43-f02a-d88e-b6a0-d030ec73f4c3@gmx.at> <2361e1aa-71d8-e04e-551e-ad0d127dcf5b@geldenhuys.co.uk> <994f192a-298e-3a89-747c-b1272014c6c3@geldenhuys.co.uk> <888ae36d-ed68-9c40-9fe1-c49e0fff9ce3@geldenhuys.co.uk> Message-ID: <6aa6c314-6549-decc-dc0c-39d8a29de5e6@windstream.net> On 08/21/2017 05:49 AM, Graeme Geldenhuys via Lazarus wrote: > On 2017-08-21 10:35, Andreas Frieß via Lazarus wrote: >> It is possible to use a standard font and give a warning instead of fire >> an exception. >> >> Eg. Font xxxx not found, using standardfont instead .... ? > > I don't like that. First, how are you going to display the warning? Remember > fpReport was designed to be able to run from console or headless servers too, > not just desktop apps. Secondly, how are you going to substitute the font? Which > font will you choose you choose Comic Sans, of course :wink: :wink: -- NOTE: No off-list assistance is given without prior approval. *Please keep mailing list traffic on the list unless* *a signed and pre-paid contract is in effect with us.* From pascaldragon at googlemail.com Mon Aug 21 17:20:35 2017 From: pascaldragon at googlemail.com (Sven Barth) Date: Mon, 21 Aug 2017 17:20:35 +0200 Subject: [Lazarus] fpReport -> Lazarus reportdsg.lpr In-Reply-To: References: <7fc26a43-f02a-d88e-b6a0-d030ec73f4c3@gmx.at> <2361e1aa-71d8-e04e-551e-ad0d127dcf5b@geldenhuys.co.uk> <994f192a-298e-3a89-747c-b1272014c6c3@geldenhuys.co.uk> <888ae36d-ed68-9c40-9fe1-c49e0fff9ce3@geldenhuys.co.uk> Message-ID: Am 21.08.2017 13:56 schrieb "Michael Van Canneyt" : > > > > On Mon, 21 Aug 2017, Sven Barth via Lazarus wrote: > >> Am 21.08.2017 11:25 schrieb "Graeme Geldenhuys via Lazarus" < >> lazarus at lists.lazarus-ide.org>: >>> >>> >>> On 2017-08-21 10:18, Michael Van Canneyt wrote: >>>>> >>>>> >>>>> >>>>> >>>>> /usr/local/share/fonts >>>>> /usr/local/lib/X11/fonts >>>>> fonts >>>>> >>>>> ~/.fonts >>>> >>>> >>>> Should indeed be easy to parse and handle... >>> >>> >>> >>> I'll make it so. I guess the best option would be to add it as an option >> >> API call, so if somebody wants it, simply call >> .AddStandardFontPaths(). For those that don't want those font paths, >> simply do nothing. >> >> Why not dynamically load the fontconfig library and ask that instead of >> manually parsing its config file? > > > > Because I didn't know such a library existed :) Ah, in that case: fontconfig is the default library to deal with font configuration on the Open Source *nix systems (Linux, FreeBSD, etc.). Regards, Sven -------------- next part -------------- An HTML attachment was scrubbed... URL: From friess at gmx.at Mon Aug 21 22:05:44 2017 From: friess at gmx.at (=?UTF-8?Q?Andreas_Frie=c3=9f?=) Date: Mon, 21 Aug 2017 22:05:44 +0200 Subject: [Lazarus] fpReport -> dll loading Windows Message-ID: <4216210c-8856-7b83-b86c-6f0762633251@gmx.at> The loading of the freetypexxxx.dll is not optimal under Windows (10). I have inserted the packages for Lazarus for fpReport and after the start i got an erroer because freetype-6.dll could not found (it reside in windows/system32) and the programm should be new installed. I know the solution, but i think in freetypeh.pp should also search in the windowspath and not only in the programm dir and load the dll dynamicly. Andreas From andrea.mauri.75 at gmail.com Tue Aug 22 16:34:50 2017 From: andrea.mauri.75 at gmail.com (Andrea Mauri) Date: Tue, 22 Aug 2017 16:34:50 +0200 Subject: [Lazarus] TFilenameedit onchange osx Message-ID: Dear all, I noticed that TFilenameedit onchange event is raised differently between win-linux and osx. Windows and Linux behave in the same way, osx differently. Onchange event is raised on windows and linux when click ok after file selection. While on osx Onchange is raised only if I directly edit the tfilenameedit. Additionally, I tried onacceptfilename. It is raised when I select a file using the dialog but TFilenameedit.Filename = '' (win, lin, osx). Any hints? Andrea Mauri From dezlov at gmail.com Wed Aug 23 10:24:53 2017 From: dezlov at gmail.com (Denis Kozlov) Date: Wed, 23 Aug 2017 09:24:53 +0100 Subject: [Lazarus] TFilenameedit onchange osx In-Reply-To: References: Message-ID: <39fed77e-7762-e053-171b-b0dd0869d2ef@gmail.com> FYI, there are few related bug reports about OnChange not firing correctly on Mac OS: https://bugs.freepascal.org/view.php?id=24009 (year 2013) https://bugs.freepascal.org/view.php?id=30167 (year 2016) Denis On 22/08/2017 15:34, Andrea Mauri via Lazarus wrote: > Dear all, > > I noticed that > TFilenameedit onchange event is raised differently between win-linux > and osx. > Windows and Linux behave in the same way, osx differently. > > Onchange event is raised on windows and linux when click ok after file > selection. While on osx Onchange is raised only if I directly edit the > tfilenameedit. > > Additionally, I tried onacceptfilename. It is raised when I select a > file using the dialog but TFilenameedit.Filename = '' (win, lin, osx). > > Any hints? > > Andrea Mauri From andrea.mauri.75 at gmail.com Wed Aug 23 12:28:28 2017 From: andrea.mauri.75 at gmail.com (Andrea Mauri) Date: Wed, 23 Aug 2017 12:28:28 +0200 Subject: [Lazarus] TFilenameedit onchange osx In-Reply-To: <39fed77e-7762-e053-171b-b0dd0869d2ef@gmail.com> References: <39fed77e-7762-e053-171b-b0dd0869d2ef@gmail.com> Message-ID: any chance to fix them? how can I help? 2017-08-23 10:24 GMT+02:00 Denis Kozlov : > FYI, there are few related bug reports about OnChange not firing correctly > on Mac OS: > https://bugs.freepascal.org/view.php?id=24009 (year 2013) > https://bugs.freepascal.org/view.php?id=30167 (year 2016) > > Denis > > > > On 22/08/2017 15:34, Andrea Mauri via Lazarus wrote: > >> Dear all, >> >> I noticed that >> TFilenameedit onchange event is raised differently between win-linux and >> osx. >> Windows and Linux behave in the same way, osx differently. >> >> Onchange event is raised on windows and linux when click ok after file >> selection. While on osx Onchange is raised only if I directly edit the >> tfilenameedit. >> >> Additionally, I tried onacceptfilename. It is raised when I select a file >> using the dialog but TFilenameedit.Filename = '' (win, lin, osx). >> >> Any hints? >> >> Andrea Mauri >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From juha.manninen62 at gmail.com Fri Aug 25 12:06:37 2017 From: juha.manninen62 at gmail.com (Juha Manninen) Date: Fri, 25 Aug 2017 13:06:37 +0300 Subject: [Lazarus] TFilenameedit onchange osx In-Reply-To: References: <39fed77e-7762-e053-171b-b0dd0869d2ef@gmail.com> Message-ID: On Wed, Aug 23, 2017 at 1:28 PM, Andrea Mauri via Lazarus wrote: > any chance to fix them? > how can I help? You can help by providing a patch that fixes them. A valid patch will be applied for sure. I found other similar bug reports and marked them as related to the ones Denis listed. Juha From andrea.mauri.75 at gmail.com Fri Aug 25 12:29:43 2017 From: andrea.mauri.75 at gmail.com (Andrea Mauri) Date: Fri, 25 Aug 2017 12:29:43 +0200 Subject: [Lazarus] TFilenameedit onchange osx In-Reply-To: References: <39fed77e-7762-e053-171b-b0dd0869d2ef@gmail.com> Message-ID: <90690720-371a-6589-9e20-bc7c410a7e1a@gmail.com> Il 25/08/2017 12:06, Juha Manninen via Lazarus ha scritto: > On Wed, Aug 23, 2017 at 1:28 PM, Andrea Mauri via Lazarus > wrote: >> any chance to fix them? >> how can I help? > > You can help by providing a patch that fixes them. A valid patch will > be applied for sure. > I found other similar bug reports and marked them as related to the > ones Denis listed. > > Juha > I would. But I think that is out of my skills. Where should I look? Any starting point? I can se this bug only on osx, and I opened my first mac last week ;-) Andrea From vojtech.cihak at atlas.cz Fri Aug 25 15:55:12 2017 From: vojtech.cihak at atlas.cz (=?utf-8?q?Vojt=C4=9Bch_=C4=8Cih=C3=A1k?=) Date: Fri, 25 Aug 2017 15:55:12 +0200 Subject: [Lazarus] MemTrain Message-ID: <20170825155512.90F7B3B5@atlas.cz> Hi,   for those who don't visit forum: I announced a very simple game for training memory: http://forum.lazarus.freepascal.org/index.php/topic,38004.0.html   Or directly on SF: https://sourceforge.net/projects/memtrain/files/   Currently sources are available only.   Enjoy, V. (Blaazen)  From juha.manninen62 at gmail.com Fri Aug 25 19:15:38 2017 From: juha.manninen62 at gmail.com (Juha Manninen) Date: Fri, 25 Aug 2017 20:15:38 +0300 Subject: [Lazarus] TFilenameedit onchange osx In-Reply-To: <90690720-371a-6589-9e20-bc7c410a7e1a@gmail.com> References: <39fed77e-7762-e053-171b-b0dd0869d2ef@gmail.com> <90690720-371a-6589-9e20-bc7c410a7e1a@gmail.com> Message-ID: On Fri, Aug 25, 2017 at 1:29 PM, Andrea Mauri via Lazarus wrote: > I would. But I think that is out of my skills. Where should I look? Any > starting point? I don't know. I don't have a Mac. In general contributors / developers just have to learn the code by debugging and experimenting, little by little. There is no shortcut for it really. > I can se this bug only on osx, and I opened my first mac last week ;-) Ok, congratulations. :) That may hinder the development of course. You must learn the OS, then setup the debugging environment and whatever is needed. I don't know details, I only read that people had trouble debugging there. Mac development has advanced slowly. Especially Cocoa should be improved ASAP. Juha From coppolastudio at gmail.com Fri Aug 25 21:33:08 2017 From: coppolastudio at gmail.com (coppolastudio) Date: Fri, 25 Aug 2017 21:33:08 +0200 Subject: [Lazarus] TFilenameedit onchange osx References: Message-ID: <651qnuhihdjojbc6krprjf1v.1503689588364@email.kingsoft.com> An HTML attachment was scrubbed... URL: From donald at ziesig.org Sun Aug 27 21:51:52 2017 From: donald at ziesig.org (Donald Ziesig) Date: Sun, 27 Aug 2017 15:51:52 -0400 Subject: [Lazarus] Debugger constantly crashing. Message-ID: <5f2fc260-796b-22c7-1f24-be00d73677af@ziesig.org> Hi All, I have been having trouble debugging some simple programs using Lazarus 1.9 with FPC 3.0.2 on Linux Mint 18. When I move my mouse over certain variables the debugger crashes with error messages similar to: The GDB command: "-data-evaluate-expression CQ2WORLDDM.CQWORLDDATA^" did not return any result. The only thing that seems to be consistent with all of the crashes is that the expression being evaluated is dereferencing a pointer. (I might be wrong about this; I just don't recall any other cases). This is really frustrating. At the point where I think I am getting close to finding the bug, the debugger crashes :'(. Its especially frustrating when I happen to move the cursor over something that I am not interested in and crash! Has anyone else seen this and come up with a solution, or should I create a bug report? Thanks, Don Ziesig From lazarus at mfriebe.de Sun Aug 27 22:43:06 2017 From: lazarus at mfriebe.de (Martin Frb) Date: Sun, 27 Aug 2017 21:43:06 +0100 Subject: [Lazarus] Debugger constantly crashing. In-Reply-To: <5f2fc260-796b-22c7-1f24-be00d73677af@ziesig.org> References: <5f2fc260-796b-22c7-1f24-be00d73677af@ziesig.org> Message-ID: On 27/08/2017 20:51, Donald Ziesig via Lazarus wrote: > > The GDB command: > "-data-evaluate-expression CQ2WORLDDM.CQWORLDDATA^" > did not return any result. > > The only thing that seems to be consistent with all of the crashes is > that the expression being evaluated is dereferencing a pointer.  (I > might be wrong about this; I just don't recall any other cases). > > Has anyone else seen this and come up with a solution, or should I > create a bug report? This is a bug in gdb, so we can not fix it on our end. But a couple of notes that may help. 1) You can turn of the debug hint somewhere in the options (codetools) IIRC 2) Try compiling with dwarf or stabs (project options / debugging). I think the default is stabs, so you should try dwarf. BUT: You need to apply that to all packages too (each package has an option). Easiest way to do this is "Additions and Overrides" 3) Try a different version of GDB. I have not tested this on Linux, but on win only. But it may be similar on Linux. My observation is that gdb at version 7.7 and above crashes more often (and especially with stabs). From donald at ziesig.org Sun Aug 27 22:54:34 2017 From: donald at ziesig.org (Donald Ziesig) Date: Sun, 27 Aug 2017 16:54:34 -0400 Subject: [Lazarus] Debugger constantly crashing. In-Reply-To: References: <5f2fc260-796b-22c7-1f24-be00d73677af@ziesig.org> Message-ID: On 08/27/2017 04:43 PM, Martin Frb via Lazarus wrote: > On 27/08/2017 20:51, Donald Ziesig via Lazarus wrote: >> >> The GDB command: >> "-data-evaluate-expression CQ2WORLDDM.CQWORLDDATA^" >> did not return any result. >> >> The only thing that seems to be consistent with all of the crashes is >> that the expression being evaluated is dereferencing a pointer. (I >> might be wrong about this; I just don't recall any other cases). >> >> Has anyone else seen this and come up with a solution, or should I >> create a bug report? > > This is a bug in gdb, so we can not fix it on our end. > > But a couple of notes that may help. > > 1) You can turn of the debug hint somewhere in the options (codetools) > IIRC > > 2) Try compiling with dwarf or stabs (project options / debugging). I > think the default is stabs, so you should try dwarf. > > BUT: You need to apply that to all packages too (each package has an > option). Easiest way to do this is "Additions and Overrides" > > 3) Try a different version of GDB. > I have not tested this on Linux, but on win only. But it may be > similar on Linux. > My observation is that gdb at version 7.7 and above crashes more often > (and especially with stabs). > > Thanks Martin. I'll try these suggestions and let you (and the list) know how they work. Don From lazarus at mfriebe.de Sun Aug 27 23:00:40 2017 From: lazarus at mfriebe.de (Martin Frb) Date: Sun, 27 Aug 2017 22:00:40 +0100 Subject: [Lazarus] Debugger constantly crashing. In-Reply-To: References: <5f2fc260-796b-22c7-1f24-be00d73677af@ziesig.org> Message-ID: <63b9bb80-2d52-cb51-34ef-0079f440f02d@mfriebe.de> On 27/08/2017 21:54, Donald Ziesig via Lazarus wrote: > On 08/27/2017 04:43 PM, Martin Frb via Lazarus wrote: >> >> 2) Try compiling with dwarf or stabs (project options / debugging). I >> think the default is stabs, so you should try dwarf. >> >> >> > Thanks Martin.  I'll try these suggestions and let you (and the list) > know how they work. Btw that is dwarf 2  (dwarf 3 is likely going to make it worse) Dwarf 2 + sets, is the recommended one. There is a wiki http://wiki.lazarus.freepascal.org/GDB_Debugger_Tips You can run the testcase (components/gdbmidebugger/test) That includes some tests, that will crash some versions of gdb. (but be fine on others). (You may or may not have to create the config files (see in folder) to run the test / and there is no real benefit in running it, other than if you want to analyse thinks in more detail....) From listbox at martoks-place.de Sun Aug 27 23:44:39 2017 From: listbox at martoks-place.de (Martok) Date: Sun, 27 Aug 2017 23:44:39 +0200 Subject: [Lazarus] Debugger constantly crashing. In-Reply-To: References: <5f2fc260-796b-22c7-1f24-be00d73677af@ziesig.org> Message-ID: > This is a bug in gdb, so we can not fix it on our end. Is this a known bug reported at upstream? Maybe even with patch that they don't want to apply (again)? If so, do you have a reference? I've seen similar errors occasionally too, and since I use custom patched gdb (on Win targets) anyway, that'd be a handy one to add. -- Martok From bo.berglund at gmail.com Wed Aug 30 08:09:44 2017 From: bo.berglund at gmail.com (Bo Berglund) Date: Wed, 30 Aug 2017 08:09:44 +0200 Subject: [Lazarus] Dangers of using Move command to insert data into a TBytes array? Message-ID: I just want to check with you which way is safer when using Move() commands in a procedure to combine two TBytes arrays by inserting one into the other at a specified point. What I need to do is the following: - Increase the size of the Dest array by the length of the Src array - Move the data following the insertion point in the Dest array towards the end starting at Index - Copy the data from the Src array into Dest at Index where the hole has been created Like this: procedure InsertBytes(var Dest: TBytes; Src: TBytes; Index: integer); var LenD, LenS: integer; begin if Length(Src) = 0 then exit; LenD := Length(Dest); LenS := Length(Src); if Index > LenD then Index := LenD; //Make an append instead SetLength(Dest, LenD + LenS); Move(Dest[Index], Dest[Index + LenS], LenD - Index); //Create space Move(Src[0], Dest[Index], LenS); //Insert data end; If the calculation of the number of bytes to move (LenD - Index) for some reason is wrong and results in too many bytes being moved, what will happen then? Will Move() overwrite whatever is following the Dest array in memory? Would it be safer to use a local intermediate array to combine Dest and Src and then in the end Move the data back into Dest? I have tested the above procedure and it looks OK, but I am worried that in some cases the same kind of construct would be wrong and maybe cause unknown side effects. I must use Move() for handling other data of various kinds like packed records and such too... -- Bo Berglund Developer in Sweden From michael at freepascal.org Wed Aug 30 09:48:47 2017 From: michael at freepascal.org (Michael Van Canneyt) Date: Wed, 30 Aug 2017 09:48:47 +0200 (CEST) Subject: [Lazarus] Dangers of using Move command to insert data into a TBytes array? In-Reply-To: References: Message-ID: On Wed, 30 Aug 2017, Bo Berglund via Lazarus wrote: > I just want to check with you which way is safer when using Move() > commands in a procedure to combine two TBytes arrays by inserting one > into the other at a specified point. > > > What I need to do is the following: > - Increase the size of the Dest array by the length of the Src array > - Move the data following the insertion point in the Dest array > towards the end starting at Index > - Copy the data from the Src array into Dest at Index where the hole > has been created > > Like this: > > procedure InsertBytes(var Dest: TBytes; Src: TBytes; Index: integer); > var > LenD, LenS: integer; > begin > if Length(Src) = 0 then exit; > LenD := Length(Dest); > LenS := Length(Src); > if Index > LenD then Index := LenD; //Make an append instead > SetLength(Dest, LenD + LenS); > Move(Dest[Index], Dest[Index + LenS], LenD - Index); //Create space > Move(Src[0], Dest[Index], LenS); //Insert data > end; > > If the calculation of the number of bytes to move (LenD - Index) for > some reason is wrong and results in too many bytes being moved, what > will happen then? Will Move() overwrite whatever is following the Dest > array in memory? Yes. > > Would it be safer to use a local intermediate array to combine Dest > and Src and then in the end Move the data back into Dest? Not really. If you calculate lengths wrong, the end result is unpredictable in any case. > > I have tested the above procedure and it looks OK, but I am worried > that in some cases the same kind of construct would be wrong and maybe > cause unknown side effects. > I must use Move() for handling other data of various kinds like packed > records and such too... If the packed records contain managed data (ansistrings and the like): Don't use move. Michael. From michael at freepascal.org Wed Aug 30 09:48:47 2017 From: michael at freepascal.org (Michael Van Canneyt) Date: Wed, 30 Aug 2017 09:48:47 +0200 (CEST) Subject: [Lazarus] Dangers of using Move command to insert data into a TBytes array? In-Reply-To: References: Message-ID: On Wed, 30 Aug 2017, Bo Berglund via Lazarus wrote: > I just want to check with you which way is safer when using Move() > commands in a procedure to combine two TBytes arrays by inserting one > into the other at a specified point. > > > What I need to do is the following: > - Increase the size of the Dest array by the length of the Src array > - Move the data following the insertion point in the Dest array > towards the end starting at Index > - Copy the data from the Src array into Dest at Index where the hole > has been created > > Like this: > > procedure InsertBytes(var Dest: TBytes; Src: TBytes; Index: integer); > var > LenD, LenS: integer; > begin > if Length(Src) = 0 then exit; > LenD := Length(Dest); > LenS := Length(Src); > if Index > LenD then Index := LenD; //Make an append instead > SetLength(Dest, LenD + LenS); > Move(Dest[Index], Dest[Index + LenS], LenD - Index); //Create space > Move(Src[0], Dest[Index], LenS); //Insert data > end; > > If the calculation of the number of bytes to move (LenD - Index) for > some reason is wrong and results in too many bytes being moved, what > will happen then? Will Move() overwrite whatever is following the Dest > array in memory? Yes. > > Would it be safer to use a local intermediate array to combine Dest > and Src and then in the end Move the data back into Dest? Not really. If you calculate lengths wrong, the end result is unpredictable in any case. > > I have tested the above procedure and it looks OK, but I am worried > that in some cases the same kind of construct would be wrong and maybe > cause unknown side effects. > I must use Move() for handling other data of various kinds like packed > records and such too... If the packed records contain managed data (ansistrings and the like): Don't use move. Michael. From markMLl.lazarus at telemetry.co.uk Wed Aug 30 23:22:45 2017 From: markMLl.lazarus at telemetry.co.uk (Mark Morgan Lloyd) Date: Wed, 30 Aug 2017 21:22:45 +0000 Subject: [Lazarus] Attaching GDB to running process Message-ID: I'm sorry to have to ask this, but can somebody remind me please how to get Lazarus to attach gdb to a running program by GDB? I think I'm having a "senior moment". (Debian on x86_64 etc.) -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] From evvke at hotmail.com Thu Aug 31 00:25:06 2017 From: evvke at hotmail.com (Cyrax) Date: Thu, 31 Aug 2017 01:25:06 +0300 Subject: [Lazarus] Attaching GDB to running process In-Reply-To: References: Message-ID: On 31/08/17 00:22, Mark Morgan Lloyd via Lazarus wrote: > I'm sorry to have to ask this, but can somebody remind me please how to > get Lazarus to attach gdb to a running program by GDB? I think I'm > having a "senior moment". > > (Debian on x86_64 etc.) > Run->Attach to program From markMLl.lazarus at telemetry.co.uk Thu Aug 31 09:09:49 2017 From: markMLl.lazarus at telemetry.co.uk (Mark Morgan Lloyd) Date: Thu, 31 Aug 2017 07:09:49 +0000 Subject: [Lazarus] Attaching GDB to running process In-Reply-To: References: Message-ID: On 30/08/17 22:30, Cyrax via Lazarus wrote: > On 31/08/17 00:22, Mark Morgan Lloyd via Lazarus wrote:> I'm sorry to > have to ask this, but can somebody remind me please how to > get Lazarus > to attach gdb to a running program by GDB? I think I'm > having a > "senior moment".> > (Debian on x86_64 etc.) > Run->Attach to program I don't appear to have that, which is odd because I'm sure I've I've used this copy of Lazarus (1.0.14) working on this project to do it a few weeks ago. I see it on 1.6.4, was it hidden on a form somewhere earlier? -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] From andrea.mauri.75 at gmail.com Thu Aug 31 12:17:52 2017 From: andrea.mauri.75 at gmail.com (Andrea Mauri) Date: Thu, 31 Aug 2017 12:17:52 +0200 Subject: [Lazarus] TFilenameedit onchange osx In-Reply-To: References: <39fed77e-7762-e053-171b-b0dd0869d2ef@gmail.com> <90690720-371a-6589-9e20-bc7c410a7e1a@gmail.com> Message-ID: <2bc04541-e369-c595-4d00-6f56176331ee@gmail.com> Il 25/08/2017 19:15, Juha Manninen via Lazarus ha scritto: > > I don't know. I don't have a Mac. > In general contributors / developers just have to learn the code by > debugging and experimenting, little by little. There is no shortcut > for it really. > Got it. > > Ok, congratulations. :) > That may hinder the development of course. You must learn the OS, then > setup the debugging environment and whatever is needed. > I don't know details, I only read that people had trouble debugging there. > Yes, there are some issues with debugging. Finally I got gdb workince lldb ing xcode is worse than gdb with lazarus. What about the fpdebugger? > Mac development has advanced slowly. Especially Cocoa should be improved ASAP. +1 > > Juha > From skalogryz.lists at gmail.com Thu Aug 31 15:43:43 2017 From: skalogryz.lists at gmail.com (Dmitry Boyarintsev) Date: Thu, 31 Aug 2017 09:43:43 -0400 Subject: [Lazarus] TFilenameedit onchange osx In-Reply-To: <39fed77e-7762-e053-171b-b0dd0869d2ef@gmail.com> References: <39fed77e-7762-e053-171b-b0dd0869d2ef@gmail.com> Message-ID: On Wed, Aug 23, 2017 at 4:24 AM, Denis Kozlov via Lazarus < lazarus at lists.lazarus-ide.org> wrote: > FYI, there are few related bug reports about OnChange not firing correctly > on Mac OS: > https://bugs.freepascal.org/view.php?id=24009 (year 2013) > https://bugs.freepascal.org/view.php?id=30167 (year 2016) > This is a common Carbon behavior (and Cocoa as well). Carbon "change" event is only triggered whenever an actual user input occurred. LCL OnChange event is triggered for both an actual user input or a programmatic change. Naturally, WSCarbon needs to updated to trigger LCL OnChange event whenever a programmatic change occurs. To be honest, it's surprising to see these issues again (a regression?) since they've been worked on back in 2009-2010. I might be wrong though, since similar problem might have been reported for TMemo, TComboBox (rather than TEdit) thanks, Dmitry -------------- next part -------------- An HTML attachment was scrubbed... URL: