In our previous episode, Felipe Monteiro de Carvalho said:
> On Mon, Dec 1, 2008 at 7:33 PM, Martin Friebe <[EMAIL PROTECTED]> wrote:
> > I suggested to have a rtl, that has overloaded functions for each string
> > type.
> > of course that sounds easier than in fact it will be.
>
> This is about t
I never suggested the RTL to be in a fixed encoding. I fully agree
that this would be far worse.
I suppose there are (quite decently workable) solutions for this. Either
the RTL (and LCL, FWIW) comes in multiple versions that are used as
appropriate (user selectable and/or automatically select
This is about the same as having all string routines in 3 flavours:
RTLString, utf-8 and utf-16
What about (real) ANSIString (OS/locale based coded) ? This needs to be
allowed as the program might need to read such files.
-Michael
___
fpc-devel m
Felipe Monteiro de Carvalho schrieb:
> On Mon, Dec 1, 2008 at 8:27 PM, Mattias Gaertner
> <[EMAIL PROTECTED]> wrote:
>> I don't see, how a TLCLStrings will *not* break Delphi and Lazarus
>> compatibility. Maybe you can give some more details, how it should work.
>
> It was just a initial idea. I n
For me, these attempts to make compiler do everything automatically sound
like getting yet another typing saver.
Maybe I am just being lazy, but it's not a typing saver but regarding
the previous not-Unicode aware versions it's more a "preventer of a
typing enhancer" :) .
OTOH it's not just
I now understand that GB2312 and JIS 0213 in fact are the ANSI code
pages 936 and 932.
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
On Tue, Dec 2, 2008 at 8:57 AM, Alexander Klenin <[EMAIL PROTECTED]> wrote:
> But Pascal still had the advantage in contests despite RTL weakness.
> I believe this comes primarily from the fact that simpler and cleaner
> syntax of Pascal
> leads to fewer mistakes, and the cost of mistake is very hi
Zitat von Michael Schnell <[EMAIL PROTECTED]>:
>
> > For me, these attempts to make compiler do everything automatically sound
> > like getting yet another typing saver.
> Maybe I am just being lazy, but it's not a typing saver but regarding
> the previous not-Unicode aware versions it's more a "p
On Tue, Dec 2, 2008 at 21:04, Felipe Monteiro de Carvalho
<[EMAIL PROTECTED]> wrote:
> What does STL offer that the FPC RTL/FCL doesn't?
Primarily a well-developed collection of algorithms and data structures
suitable for natural and efficient integration into application programs.
The last part
IMHO it has been already discussed too often.
I did not start it and only 1% of the contributions are mine - and yours
-, so quite obviously there is a decent common wish for a solution of
what is percept as a problem.
-Michael
___
fpc-devel ma
Alexander Klenin schrieb:
> partially implemented, so I believe current functionality is not enough yet
> to create anything competitive with the STL.
>
Did you ever try to debug STL based programs even with a in this regard
good debugger?
___
fpc-devel
avoids automatic
conversion between types as much as possible.
I feel that it's a goody of a strongly typed language that automatic
type conversions can be done by creating the appropriate code statically
instead of having this embedded in the objects as with variants.
If doing a simple a
In our previous episode, Graeme Geldenhuys said:
> Why reinvent the wheel with all these different string types and
> round-about discussions etc... Can we learn something from other
> multi-platform frameworks that solved these problems ages ago!
Who said they did? Who says their solution is mo
Graeme Geldenhuys wrote:
So would it maybe help if we took a peek at what those frameworks have
done. Clearly they managed to do it right as no developers or users
are complaining! So I guess Free Pascal could learn from them and
don't have to go through the whole R&D process. Study what those
The type is called ansistring simply for backwards compatibility.
You could start arguing that everything should be intuitive. Take C
for example. What does the && operator tell you about what it does?
Shouldn't it have a intuitive form? But in the end this is how the
language is and this is a use
On Tue, Dec 2, 2008 at 10:47 AM, Sergei Gorelkin
<[EMAIL PROTECTED]> wrote:
> Third, QT is a shared library (and Java framework may also be treated as
> such), and it implements huge Unicode conversion tables without putting them
> into every executable.
Not every executable. Only if you want to u
On Tue, Dec 2, 2008 at 2:47 PM, Sergei Gorelkin <[EMAIL PROTECTED]> wrote:
>
> Unfortunately what those frameworks did isn't directly applicable to FPC.
> First, as I understand, they have only one (UTF-16) string type. This is
> good because it avoids whatever mess related to conversions, but not
Graeme Geldenhuys wrote:
Then for backward compatibility use UTF-8 as the only string type.
That's what UTF-8 was designed for - backward compatibility. That's
also the reason LCL uses UTF-8.
You cannot use *only* utf-8, the existing ShortString, AnsiString and
Wide/UnicodeString types have t
On Tue, Dec 2, 2008 at 2:31 PM, Marco van de Voort <[EMAIL PROTECTED]> wrote:
>> Why reinvent the wheel with all these different string types and
>> round-about discussions etc... Can we learn something from other
>> multi-platform frameworks that solved these problems ages ago!
>
> Who said they
In our previous episode, Sergei Gorelkin said:
> > don't have to go through the whole R&D process. Study what those two
> > frameworks did and apply the same thing to Free Pascal!
> >
> Unfortunately what those frameworks did isn't directly applicable to FPC.
> First, as I understand, they have on
Don't forget that the ansistring type is actually multiple encodings and
even multi byte (even not considering UTF-8). The point is: nobody took
care of it.
IMHO a major confusion is generated by calling a string that is supposed
to hold UTF8 data "ANSIString". This never should have happene
Mattias Gärtner schrieb:
> Zitat von Florian Klaempfl <[EMAIL PROTECTED]>:
>
>> Mattias Gaertner schrieb:
>>> You can optimize for one encoding or optimize for one per platform. I
>>> know how to optimize for widestrings, for ansistring and for UTF-8
>>> strings, but I have no experience in optimi
I meant more that a lot of people simply ignored in their code that
ansistrings could be also multibyte even not considering UTF-8.
Ignoring that ANSI Characters > $7F are locale depending makes a program
work perfectly in a single country and mostly decently in many others.
Ignoring that
Op Tue, 2 Dec 2008, schreef Michael Schnell:
Nobody talks in this case about UTF-8. Even *ANSIstrings* in there
native meaning can contain multi byte chars, there are *multi byte* ansi
char sets.
If there is a widely used multi-byte ANSI encoding, why so we need Unicode ?
IMHO the introduc
Michael Schnell schrieb:
>
>> Don't forget that the ansistring type is actually multiple encodings and
>> even multi byte (even not considering UTF-8). The point is: nobody took
>> care of it.
>>
> IMHO a major confusion is generated by calling a string that is supposed
> to hold UTF8 data "ANS
In our previous episode, Graeme Geldenhuys said:
> >> Why reinvent the wheel with all these different string types and
> >> round-about discussions etc... Can we learn something from other
> >> multi-platform frameworks that solved these problems ages ago!
> >
> > Who said they did?
>
> Well, who
On Tue, Dec 2, 2008 at 22:15, Florian Klaempfl <[EMAIL PROTECTED]> wrote:
> Alexander Klenin schrieb:
>> partially implemented, so I believe current functionality is not enough yet
>> to create anything competitive with the STL.
>>
>
> Did you ever try to debug STL based programs even with a in thi
So, really? What is not supported?
If just ignoring the fact is enough support, OK, it's supported :).
... tell this 1+ Billion (Billion=10^9 in this case) people in China.
I did not know (or suppose) that code used for Chinese characters is
called "ANSI" ("American National Standards I
Michael Schnell wrote:
The more I think about it the more I like this solution. I think it's
better then the previous idea of a string with encode information
inside it.
Would Lazarus be able to follow ?
Do you think it's possible to have the compiler take care of any
necessary conversion
On Tue, Dec 2, 2008 at 4:01 PM, Marco van de Voort <[EMAIL PROTECTED]> wrote:
>
> I can only guess about QT's reasons. In Kylix times I once heard a rumour
> that QT was mostly modeled after NT's api philosophy, to make it programmers
> easier to migrate.
I have never heard that and can't think t
Michael Schnell schrieb:
>
>> Nobody talks in this case about UTF-8. Even *ANSIstrings* in there
>> native meaning can contain multi byte chars, there are *multi byte* ansi
>> char sets.
> If there is a widely used multi-byte ANSI encoding, why so we need
> Unicode ?
>
> IMHO the introduction of
On 02 Dec 2008, at 03:11, Sooky Boo wrote:
In c++ the register keyword tries to make the compiler use the CPU's
registers if possible for the variable being defined.
The register keyword is completely ignored by pretty much any modern
C(++) compiler out there.
Jonas
_
On Tue, December 2, 2008 13:59, Graeme Geldenhuys wrote:
> On Tue, Dec 2, 2008 at 2:47 PM, Sergei Gorelkin <[EMAIL PROTECTED]>
> wrote:
>>
>> Unfortunately what those frameworks did isn't directly applicable to
>> FPC.
>> First, as I understand, they have only one (UTF-16) string type. This is
>> g
Felipe Monteiro de Carvalho wrote:
Ignore the name "ansi". Take it as a string type with the system
encoding. I think it will solve the confusion.
Of course if you ignore "ANSI" and just use the type named "String"
there is no confusion as it's clear that the coding is not predefined.
That
Michael Schnell schrieb:
>
>> I meant more that a lot of people simply ignored in their code that
>> ansistrings could be also multibyte even not considering UTF-8.
>>
> Ignoring that ANSI Characters > $7F are locale depending makes a program
> work perfectly in a single country and mostly dece
The point is: if everybody takes care of the fact that ansistrings can
be multibyte, having utf-8 in ansistrings (if it's the locale encoding),
is no big deal at all.
I do understand. But (in a real world) do you know anybody who does.
If it would be "appropriate" for ANSI code handling to
Mattias Gaertner schrieb:
> You can optimize for one encoding or optimize for one per platform. I
> know how to optimize for widestrings, for ansistring and for UTF-8
> strings, but I have no experience in optimizing for multiple
> encodings.
Don't forget that the ansistring type is actually mult
Alexander Klenin schrieb:
> On Tue, Dec 2, 2008 at 22:15, Florian Klaempfl <[EMAIL PROTECTED]> wrote:
>> Alexander Klenin schrieb:
>>> partially implemented, so I believe current functionality is not enough yet
>>> to create anything competitive with the STL.
>>>
>> Did you ever try to debug STL ba
Michael Schnell schrieb:
>
>> So, really? What is not supported?
>>
> If just ignoring the fact is enough support, OK, it's supported :).
What FUD is this? Pleaes give an example where the FPC compiler doesn't
handle multi byte ansistrings properly.
Or do you just want to troll around? This p
Florian Klaempfl schrieb:
> Alexander Klenin schrieb:
>> On Tue, Dec 2, 2008 at 22:15, Florian Klaempfl <[EMAIL PROTECTED]> wrote:
>>> Alexander Klenin schrieb:
partially implemented, so I believe current functionality is not enough yet
to create anything competitive with the STL.
>>
Michael Schnell schrieb:
>
>>> Ignoring that ANSI Characters > $7F are locale depending makes a program
>>> work perfectly in a single country and mostly decently in many others.
>>>
>>
>> So it works in far east with its multi byte ansi encodings?
>>
> These of course are not part of the
It is not helpful because on an utf-8 system ansistring contains utf-8.
Ansistring just means: use the system locale 8 bit encoding.
I meant it would be helpful to (optionally) have a complete ANSI based
system (as was the previous version of Lazarus and FPC).
I don't understand what you m
In our previous episode, Micha Nelissen said:
> > There are an immense amount of similar examples possible (and if you add
> > operator overloading in the mix, it increases exponentially), and you'd
> > get a huge amount of "can't decide which overloaded function to call"
> > errors even if the
Zitat von Florian Klaempfl <[EMAIL PROTECTED]>:
> Mattias Gaertner schrieb:
> > You can optimize for one encoding or optimize for one per platform. I
> > know how to optimize for widestrings, for ansistring and for UTF-8
> > strings, but I have no experience in optimizing for multiple
> > encoding
Nobody talks in this case about UTF-8. Even *ANSIstrings* in there
native meaning can contain multi byte chars, there are *multi byte* ansi
char sets.
If there is a widely used multi-byte ANSI encoding, why so we need
Unicode ?
IMHO the introduction of Unicode has been necessary as (like you
If just ignoring the fact is enough support, OK, it's supported :).
What FUD is this? Pleaes give an example where the FPC compiler doesn't
handle multi byte ansistrings properly.
Sorry for bad language :( ! I did not mean to be aggressive. (Did you
see the smile indicator ?)
I di
It simply needs no explicit support except what it has already. Mainly
the rtl and the user program has to take care of it and we did this
already in the rtl but the compiler required no fix in this regard so far.
I do see your point !
But my point is that with the introduction of Unicode,
Ignoring that ANSI Characters > $7F are locale depending makes a program
work perfectly in a single country and mostly decently in many others.
So it works in far east with its multi byte ansi encodings?
These of course are not part of the "many others". (BTW handling Russian
with ANS
Thanks
On Tue, Dec 2, 2008 at 8:07 AM, Jonas Maebe <[EMAIL PROTECTED]>wrote:
>
> On 02 Dec 2008, at 03:11, Sooky Boo wrote:
>
> In c++ the register keyword tries to make the compiler use the CPU's
>> registers if possible for the variable being defined.
>>
>
> The register keyword is completely
Michael Schnell schrieb:
>
>>> If just ignoring the fact is enough support, OK, it's supported :).
>>>
>>
>> What FUD is this? Pleaes give an example where the FPC compiler doesn't
>> handle multi byte ansistrings properly.
>>
> Sorry for bad language :( ! I did not mean to be aggressive.
Op Tue, 2 Dec 2008, schreef Michael Schnell:
Thanks for pointing this out.
GB2312 suits them well. Likewise, JIS 0213 suits the Japanese well.
Are these called "ANSI" ?
Yes, code page 936 and code page 932 are valid ANSI code pages.
These standards by themselves of course not, because t
Michael Schnell schrieb:
> Felipe Monteiro de Carvalho wrote:
>> Ignore the name "ansi". Take it as a string type with the system
>> encoding. I think it will solve the confusion.
>>
> Of course if you ignore "ANSI" and just use the type named "String"
> there is no confusion as it's clear that
On Tue, Dec 2, 2008 at 17:14, Daniël Mantione
<[EMAIL PROTECTED]> wrote:
>> The rumored reason was that Delphi gives "unfair advantage" to teams
>> (mostly Russian ones) using it.
> The requirement to offer a Pascal programming environment has been removed.
> Individual ACM contests are free to of
Btw will the LCL remain forcedly UTF-8 ? I thought the current Lazarus
unicode support was temporary and all options were still open, depending on
the outcome of FPC unicode support options?
I understand they could not do it differently (other than just providing
no Unicode support at all), may
Op Tue, 2 Dec 2008, schreef Michael Schnell:
I supposed one of the main intentions for the move to Unicode was the ability
to support Chinese above all. So they did not seem to have been content with
what was done before.
Is anybody from China here to offer the footage ?
It is not the Chi
On Tue, Dec 2, 2008 at 9:00 AM, Michael Schnell <[EMAIL PROTECTED]> wrote:
> I still don't understand what ANSI has to do with "System".
Ignore the name "ansi". Take it as a string type with the system
encoding. I think it will solve the confusion.
--
Felipe Monteiro de Carvalho
The more I think about it the more I like this solution. I think it's
better then the previous idea of a string with encode information
inside it.
Would Lazarus be able to follow ?
Do you think it's possible to have the compiler take care of any
necessary conversions automatically ?
-Mic
Zitat von Michael Schnell <[EMAIL PROTECTED]>:
>
> > The point is: if everybody takes care of the fact that ansistrings can
> > be multibyte, having utf-8 in ansistrings (if it's the locale encoding),
> > is no big deal at all.
> >
> I do understand. But (in a real world) do you know anybody who d
Thanks for pointing this out.
GB2312 suits them well. Likewise, JIS 0213 suits the Japanese well.
Are these called "ANSI" ?
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Hi,
Why reinvent the wheel with all these different string types and
round-about discussions etc... Can we learn something from other
multi-platform frameworks that solved these problems ages ago! I
Google'd and couldn't even find any message thread about programmers
complaining about unicode an
Michael Schnell schrieb:
> Thanks for pointing this out.
>>
>> GB2312 suits them well. Likewise, JIS 0213 suits the Japanese well.
> Are these called "ANSI" ?
Every well educated windows programmer knows that the ansi
functions/strings whatever are not limited to the so-called "ansi" code
pages (
UTF-8 is unicode and it is the system encoding on linux, OS X, some BSDs and
Solaris. So ansistrings are UTF-8 there.
I still don't understand what ANSI has to do with "System".
AFAIK, The term "ANSI Code" stands for a (codepage depending) definition
for a character encoding and Unicode is
Michael Schnell schrieb:
>
>> The point is: if everybody takes care of the fact that ansistrings can
>> be multibyte, having utf-8 in ansistrings (if it's the locale encoding),
>> is no big deal at all.
>>
> I do understand. But (in a real world) do you know anybody who does.
>
> If it would b
Not to mention: What would the alternative be?
Even if I am not satisfied with the current state of Lazarus on that
behalf, I would not dare to suggest that Lazarus should do any change
here before the next version of FPC offers a new string handling with
either a string type that knows it
Hello,
I tryed to create a test case based on some previous discussion and
the examples:
http://svn.freepascal.org/cgi-bin/viewvc.cgi?view=rev&revision=12290
Why don't the test cases have "program ..." ?
And what does the numbering mean?
thanks,
--
Felipe Monteiro de Carvalho
Ah, and why is it written that test cases should return 0 but none of
them actually do that? Is it the standard result?
--
Felipe Monteiro de Carvalho
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo
Op dinsdag 02-12-2008 om 14:03 uur [tijdzone -0200], schreef Felipe
Monteiro de Carvalho:
> Hello,
>
> I tryed to create a test case based on some previous discussion and
> the examples:
>
> http://svn.freepascal.org/cgi-bin/viewvc.cgi?view=rev&revision=12290
>
> Why don't the test cases have "p
On Tue, Dec 2, 2008 at 2:22 PM, Joost van der Sluis <[EMAIL PROTECTED]> wrote:
> Why should they? I think that those people writing those tests were
> lazy.
well, usually I expect my pascal source to look like a pascal source,
which includes starting with program or unit. I assume that program is
On 02 Dec 2008, at 17:03, Felipe Monteiro de Carvalho wrote:
I tryed to create a test case based on some previous discussion and
the examples:
http://svn.freepascal.org/cgi-bin/viewvc.cgi?view=rev&revision=12290
That test should be moved though. Tests in the standard test
directories canno
Done, except for regenerating the makefile
--
Felipe Monteiro de Carvalho
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
On 02 Dec 2008, at 17:03, Felipe Monteiro de Carvalho wrote:
I tryed to create a test case based on some previous discussion and
the examples:
http://svn.freepascal.org/cgi-bin/viewvc.cgi?view=rev&revision=12290
Why don't the test cases have "program ..." ?
Because the "program ..." stateme
Marco van de Voort wrote:
In our previous episode, Mark Morgan Lloyd said:
Looking at 2.2.3 on sparc-linux I see that libc.ppu etc. is no longer
being built, it is however built for i386 and arm and for 2.2.0 and
older. Is this intentional?
To be honest I can't remember why I needed this but
72 matches
Mail list logo
