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 TP/
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
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
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
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 Cha
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
La
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 b
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 th
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
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 wh
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
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.
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 awa
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 t
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
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
> ass
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(),
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",
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
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
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 n
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" co
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 t
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 al
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 po
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 be
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/Unicod
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?
Becaus
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 So
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 codepoi
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
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 TSt
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 nat
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 n
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
--
__
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 an
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
> "dynamicst
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).
Unfortunate
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
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 (
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 "code
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 (f
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 brai
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 "dynamicstr
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
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
--
___
Lazarus mailing lis
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
Lazarus@lists.l
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
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).
Mich
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
https://lists.lazarus-ide.org/
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
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 com
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
--
___
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.
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.
-Michae
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 TStr
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
enti
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 mentioni
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.
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
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
--
___
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
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 -
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 colle
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
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, e
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 i
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 u
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 ar
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 awar
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
https://lists.lazarus-ide.
71 matches
Mail list logo