Re: [Lazarus] The new kid is growing up fast

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 -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org

Re: [Lazarus] String vs WideString

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 --

[Lazarus] OpenGL 4.6 bindings and generator

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

Re: [Lazarus] String vs WideString

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 -- ___ Lazarus mailing list Lazarus@lists.lazarus-ide.org

Re: [Lazarus] String vs WideString

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

Re: [Lazarus] String vs WideString

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

Re: [Lazarus] String vs WideString

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

Re: [Lazarus] String vs WideString

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.

Re: [Lazarus] String vs WideString

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

Re: [Lazarus] String vs WideString

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 -

Re: [Lazarus] String vs WideString

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

Re: [Lazarus] String vs WideString

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

Re: [Lazarus] String vs WideString

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

Re: [Lazarus] dynamic string proposal

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

Re: [Lazarus] String vs WideString

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

Re: [Lazarus] String vs WideString

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

Re: [Lazarus] String vs WideString

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

Re: [Lazarus] String vs WideString

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

Re: [Lazarus] String vs WideString

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

Re: [Lazarus] String vs WideString

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 -- ___ Lazarus mailing list

Re: [Lazarus] String vs WideString

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

Re: [Lazarus] dynamic string proposal

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).

Re: [Lazarus] dynamic string proposal

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

Re: [Lazarus] dynamic string proposal

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

Re: [Lazarus] dynamic string proposal

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

Re: [Lazarus] dynamic string proposal

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

Re: [Lazarus] dynamic string proposal

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

Re: [Lazarus] dynamic string proposal

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

Re: [Lazarus] dynamic string proposal

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

Re: [Lazarus] dynamic string proposal

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

Re: [Lazarus] dynamic string proposal

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,

Re: [Lazarus] dynamic string proposal

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

Re: [Lazarus] GlobalMemoryStatus is Windows only, how to get installed RAM on Linux ?

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

Re: [Lazarus] dynamic string proposal

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

Re: [Lazarus] String vs WideString

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

[Lazarus] GlobalMemoryStatus is Windows only, how to get installed RAM on Linux ?

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 --

Re: [Lazarus] dynamic string proposal

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

Re: [Lazarus] dynamic string proposal

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

Re: [Lazarus] dynamic string proposal

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

Re: [Lazarus] dynamic string proposal

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?

Re: [Lazarus] String vs WideString

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

Re: [Lazarus] dynamic string proposal

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

Re: [Lazarus] dynamic string proposal

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

Re: [Lazarus] String vs WideString

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,

Re: [Lazarus] dynamic string proposal

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",

Re: [Lazarus] dynamic string proposal

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],

Re: [Lazarus] dynamic string proposal

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

Re: [Lazarus] String vs WideString

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

Re: [Lazarus] String vs WideString

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

Re: [Lazarus] String vs WideString

Am 17.08.2017 04:16 schrieb "wkitty42--- via Lazarus" < lazarus@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

Re: [Lazarus] String vs WideString

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

Re: [Lazarus] String vs WideString

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

Re: [Lazarus] dynamic string proposal

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

Re: [Lazarus] dynamic string proposal

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

Re: [Lazarus] String vs WideString

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

Re: [Lazarus] String vs WideString

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.

Re: [Lazarus] String vs WideString

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

Re: [Lazarus] dynamic string proposal

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

Re: [Lazarus] String vs WideString

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

Re: [Lazarus] String vs WideString

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 -- ___ Lazarus mailing list

Re: [Lazarus] String vs WideString

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