Hi,
A Russian user raised the issue in the fpGUI newsgroups... fpGUI uses
UTF-8 as the internal string encoding. He noticed that the File Dialog
which displays the file sizes with thousand separators were totally
blank. On further investigation he noticed that it was FormatFloat()
that caused th
On Tue, Jul 29, 2008 at 9:54 AM, Graeme Geldenhuys
<[EMAIL PROTECTED]> wrote:
> Hi,
>
> A Russian user raised the issue in the fpGUI newsgroups... fpGUI uses
> UTF-8 as the internal string encoding. He noticed that the File Dialog
> which displays the file sizes with thousand separators were total
Op Tue, 29 Jul 2008, schreef Graeme Geldenhuys:
Hi,
A Russian user raised the issue in the fpGUI newsgroups... fpGUI uses
UTF-8 as the internal string encoding. He noticed that the File Dialog
which displays the file sizes with thousand separators were totally
blank. On further investigatio
Daniël Mantione wrote:
is no proper solution, MBCS requires it to be a string rather than a
char, but compatibility requires it to be a char. Which means you are
Isn't a string backward compatible with a Char?
Micha
___
fpc-devel maillist - fpc-de
On Tue, Jul 29, 2008 at 10:16 AM, Daniël Mantione
<[EMAIL PROTECTED]> wrote:
> As a workaround, it can be converted into a normal breaking space. There is
> no proper solution, MBCS requires it to be a string rather than a char, but
> compatibility requires it to be a char. Which means you are limi
Op Tue, 29 Jul 2008, schreef Micha Nelissen:
Daniël Mantione wrote:
is no proper solution, MBCS requires it to be a string rather than a char,
but compatibility requires it to be a char. Which means you are
Isn't a string backward compatible with a Char?
No. A char can be automatically t
> Dani?l Mantione wrote:
> > is no proper solution, MBCS requires it to be a string rather than a
> > char, but compatibility requires it to be a char. Which means you are
>
> Isn't a string backward compatible with a Char?
No. You can't typecast or ORD() it anymore, or subtract other chars fr
On Tue, Jul 29, 2008 at 10:25 AM, Micha Nelissen <[EMAIL PROTECTED]> wrote:
>
> Isn't a string backward compatible with a Char?
I don't understand your question? Ansi Char is always 1 bytes. A
UTF-8 character can be anything from 1-4 bytes. The non-breaking
spaces is such a case, being 2 bytes a
> <[EMAIL PROTECTED]> wrote:
> > As a workaround, it can be converted into a normal breaking space. There is
> > no proper solution, MBCS requires it to be a string rather than a char, but
> > compatibility requires it to be a char. Which means you are limited to SBCS
> > compatible thousand separa
Op Tue, 29 Jul 2008, schreef Graeme Geldenhuys:
On Tue, Jul 29, 2008 at 10:16 AM, Daniël Mantione
<[EMAIL PROTECTED]> wrote:
As a workaround, it can be converted into a normal breaking space. There is
no proper solution, MBCS requires it to be a string rather than a char, but
compatibility re
On Tue, Jul 29, 2008 at 10:30 AM, Marco van de Voort <[EMAIL PROTECTED]> wrote:
>>
>> This is what the Russian user had to revert to, using a normal $20
>> (space) character. But seeing that Delphi is now going to be fully
>> Unicode compliant, surely we need to attend to these issues as well in
>
> On Tue, Jul 29, 2008 at 10:30 AM, Marco van de Voort <[EMAIL PROTECTED]>
> wrote:
> > of little ad-hoc changes to support workarounds.
>
> I did not suggest ad-hoc changes, I meant FPC should fully support
> unicode strings as Delphi is doing in the next release. Unicode is
> not something new
On Tue, Jul 29, 2008 at 10:34 AM, Daniël Mantione
<[EMAIL PROTECTED]> wrote:
>
> Delphi will do char=widechar, which will solve this. It is likely FPC will
> follow, but that doesn't change anything for the situation which is that we
> have a sysutils unit that has not been designed for UTF-8 usage
Op Tue, 29 Jul 2008, schreef Graeme Geldenhuys:
On Tue, Jul 29, 2008 at 10:30 AM, Marco van de Voort <[EMAIL PROTECTED]> wrote:
This is what the Russian user had to revert to, using a normal $20
(space) character. But seeing that Delphi is now going to be fully
Unicode compliant, surely we
On Tuesday 29 July 2008 09.54:54 Graeme Geldenhuys wrote:
>
> A Russian user raised the issue in the fpGUI newsgroups... fpGUI uses
> UTF-8 as the internal string encoding. He noticed that the File Dialog
> which displays the file sizes with thousand separators were totally
> blank. On further in
On Tue, Jul 29, 2008 at 10:45 AM, Marco van de Voort <[EMAIL PROTECTED]> wrote:
>> same boat. I don't see any point in waiting for Delphi, after all, we
>> may NOT look at their implementation anyway!
>
> No, but we can try to keep compability.
>
>> Is there any FPC discussions as to how this is g
It seems that currently, GetAppConfigDir performs rather incosistently.
On Unix, it returns path with trailing pathdelim, on windows it returns
path with random trailing path delim (depends on which branch, see code).
What should it be then?
Considering the importance of this function to prog
Op Tue, 29 Jul 2008, schreef Graeme Geldenhuys:
On Tue, Jul 29, 2008 at 10:45 AM, Marco van de Voort <[EMAIL PROTECTED]> wrote:
same boat. I don't see any point in waiting for Delphi, after all, we
may NOT look at their implementation anyway!
No, but we can try to keep compability.
Is th
On Tue, Jul 29, 2008 at 10:45 AM, Daniël Mantione
<[EMAIL PROTECTED]> wrote:
> The developers haven't talked about it yet, but I can imagine we will have
> some target platforms where sizeof(char)=1, which would provide for 100%
> compatibility with old code and some platforms where sizeof(char)=2,
On Tue, Jul 29, 2008 at 11:07 AM, Martin Schreiber <[EMAIL PROTECTED]> wrote:
>
> MSEgui has a widestring version of the FormatFloat function
> (lib/common/kernel/mseformatstr.pas formatfloatmse). There were no bug
> reports from Russian users, so it seems to work, although I did not test the
> U+0
Op Tue, 29 Jul 2008, schreef Graeme Geldenhuys:
On Tue, Jul 29, 2008 at 10:45 AM, Daniël Mantione
<[EMAIL PROTECTED]> wrote:
The developers haven't talked about it yet, but I can imagine we will have
some target platforms where sizeof(char)=1, which would provide for 100%
compatibility with o
Marco van de Voort wrote:
Dani?l Mantione wrote:
is no proper solution, MBCS requires it to be a string rather than a
char, but compatibility requires it to be a char. Which means you are
Isn't a string backward compatible with a Char?
No. You can't typecast or ORD() it anymore, or subtract
> On Tue, Jul 29, 2008 at 10:45 AM, Marco van de Voort <[EMAIL PROTECTED]>
> wrote:
> > There have been, but they are now postponed till we have real Tiburon usage
> > data.
>
> So FPC plans to always be worse off than Delphi. :-(
Well, of course. We have more requirements!? Multi-platform and
> On Tue, Jul 29, 2008 at 10:45 AM, Dani?l Mantione
> <[EMAIL PROTECTED]> wrote:
> > The developers haven't talked about it yet, but I can imagine we will have
> > some target platforms where sizeof(char)=1, which would provide for 100%
> > compatibility with old code and some platforms where sizeo
> Op Tue, 29 Jul 2008, schreef Graeme Geldenhuys:
> >> will provide the unicode support for the future.
> >
> > Sorry, but a unicode character can be anything from 1-4 bytes. 2
> > bytes will hardly cover the full unicode character range.
>
> Please read http://unicode.org/notes/tn12/ why using 2
Op Tue, 29 Jul 2008, schreef Micha Nelissen:
Marco van de Voort wrote:
Dani?l Mantione wrote:
is no proper solution, MBCS requires it to be a string rather than a
char, but compatibility requires it to be a char. Which means you are
Isn't a string backward compatible with a Char?
No. You
On Tue, Jul 29, 2008 at 11:18 AM, Daniël Mantione
<[EMAIL PROTECTED]> wrote:
>> developer demand. So now FPC wants to be even more behind, because we
>> need to wait for Delphi to one day get there act together. :-(
>
> FPC behind? What are you talking of man? :)
I knew that statement would get
> Op Tue, 29 Jul 2008, schreef Graeme Geldenhuys:
> interrest of everyone here. Borland, oops, Codegear, whoops, Embarcadero,
You forgot Inprise and Devco :-) And codegear is still good, since the
Delphi oriented division retains that name.
___
fpc-dev
Op Tue, 29 Jul 2008, schreef Graeme Geldenhuys:
Good. MSEIDE is quiet a bit ahead because it made the switch to
widechar/strings from the start.
Pity FPC could do such a bold move. ;-) Imagine how much less work
Martin would have had to do.
True. Because of the influence of Lazarus, the F
Because of
that, Delphi language features are very behind compared to the
developer demand.
In my personal view, there are very few points that are shared by Delphi
and FP and that are "very behind compared to the developer demand".
The main of these is multi-threading support.
While both
On Tue, Jul 29, 2008 at 10:27 AM, Graeme Geldenhuys
<[EMAIL PROTECTED]> wrote:
> On Tue, Jul 29, 2008 at 10:16 AM, Daniël Mantione
> <[EMAIL PROTECTED]> wrote:
>> As a workaround, it can be converted into a normal breaking space. There is
>> no proper solution, MBCS requires it to be a string rathe
Michael Van Canneyt wrote / napísal(a):
On Tue, 29 Jul 2008, Ales Katona wrote:
It seems that currently, GetAppConfigDir performs rather incosistently.
On Unix, it returns path with trailing pathdelim, on windows it returns path
with random trailing path delim (depends on which branch, see
On Tue, 29 Jul 2008, Ales Katona wrote:
> It seems that currently, GetAppConfigDir performs rather incosistently.
>
> On Unix, it returns path with trailing pathdelim, on windows it returns path
> with random trailing path delim (depends on which branch, see code).
>
> What should it be then?
Op Tue, 29 Jul 2008, schreef Graeme Geldenhuys:
So back to my original question :)
Due to ThousandSeparator being a Char type, is using a normal space
($20) the only available option for Russian users, using the current
RTL implementation? Though this might cause issues in text wrapping
On Tue, 29 Jul 2008, Ales Katona wrote:
> Michael Van Canneyt wrote / napísal(a):
> > On Tue, 29 Jul 2008, Ales Katona wrote:
> >
> >
> > > It seems that currently, GetAppConfigDir performs rather incosistently.
> > >
> > > On Unix, it returns path with trailing pathdelim, on windows it retu
>
>
> On Tue, 29 Jul 2008, Graeme Geldenhuys wrote:
>
> > On Tue, Jul 29, 2008 at 10:27 AM, Graeme Geldenhuys
> <[EMAIL PROTECTED]> wrote:
> > On Tue, Jul 29, 2008 at 10:16 AM, Daniël Mantione
> > <[EMAIL PROTECTED]> wrote:
> >> As a workaround, it can be converted into a normal breaking space.
>> As far as I heard we are already incompatible with Delphi regarding
>> Generics (I don't know generics, I just heard of them). So even though
>> FPC has Generics for some time, nobody can use it, because it's
>> incompatible with Delphi.
>
> We will see how that pans out in time. Maybe we'll sup
So FPC plans to always be worse off than Delphi. :-( I really think
playing 'catchup' with somebody like Delphi is not a good thing. They
have different goals as far as I can see, plus their future doesn't
look bright (for a very long time now). Delphi tries to compete with
Microsoft using Micro
The main of these is multi-threading support.
I also demand this support. :)
I believe FPC team could provide this feature. They are genius. But, I'm
afraid, they don't want to provide it simply because Delphi doesn't have
it (yet). They don't want FPC being incompatible with Delphi. :-P
I
Op Tue, 29 Jul 2008, schreef Bee:
So FPC plans to always be worse off than Delphi. :-( I really think
playing 'catchup' with somebody like Delphi is not a good thing. They
have different goals as far as I can see, plus their future doesn't
look bright (for a very long time now). Delphi tries
I believe FPC team could provide this feature. They are genius. But,
I'm afraid, they don't want to provide it simply because Delphi
doesn't have it (yet). They don't want FPC being incompatible with
Delphi. :-P
Adding some keywords would it not make incompatible. To stay compatible
you jus
Bee wrote:
I don't understand why FPC has DELPHI MODE directive in the first place
if FPC don't want to be different with Delphi. Maybe FPC should
eliminate this directive and make it as the default mode. :-P
This is exactly the reason. Strings and API touches everything, while
generics are a
Original-Nachricht
> Datum: Tue, 29 Jul 2008 19:48:46 +0700
> Von: Bee <[EMAIL PROTECTED]>
> An: FPC developers\' list
> Betreff: Re: [fpc-devel] Russian locale information not compatible with FPC
> locale variables
>
> > Unicode is another issue. Delphi dictates there design
FPC has chances to become the leader of object pascal native compiler
since Delphi was starting to die after Delphi 7. But, instead of
taking the lead, FPC let itself and the users down in the name of
"compatibility". What a shame! :-P
...
FPC could lead the object pascal "standard" and make
> > FPC could lead the object pascal "standard" and make Borland /CodeGear
> > /Embarcadero /whatever follows what FPC had done. Not the other way
> > around. How can FPC become a better compiler than Delphi if FPC
> > doesn't have the gut to be the best?! :(
> IMHO, Oxygen is the "leader of obj
Op Tue, 29 Jul 2008, schreef "Vinzent Höfler":
Original-Nachricht
Datum: Tue, 29 Jul 2008 19:48:46 +0700
Von: Bee <[EMAIL PROTECTED]>
An: FPC developers\' list
Betreff: Re: [fpc-devel] Russian locale information not compatible with FPC
locale variables
Unicode is anot
Why, according to you, is Oxygen Object Pascal at all? Aside from their
advertizements? Just if you compare the base subset ?
Is there some independent definition of the term "Object Pascal" ? I
don't suppose so. So they are right to claim that they are compatible to
Object pascal :) .
B
> > Why, according to you, is Oxygen Object Pascal at all? Aside from their
> > advertizements? Just if you compare the base subset ?
> >
> Is there some independent definition of the term "Object Pascal" ? I
> don't suppose so.
Well, there is the actual Object Pascal standard draft. Delphi
On Tue, Jul 29, 2008 at 3:08 PM, "Vinzent Höfler"
<[EMAIL PROTECTED]> wrote:
>
> Well, I second that. Especially because the "Delphi" implementation seems to
> be so Win32-centric, that copying it would be close to useless on platforms
> other than Windows. As far as I understand there is no such
> http://blogs.codegear.com/abauer/2008/07/16/38864/
This is all known and processed on July 17th.
> type
> MyString = type AnsiString(<1..65534>);
>
> were 1..65534 is the Windows codepage number.
Elegant is different, but a reason incompatability? Also note Daniel's
remark about codepage
Ales Katona wrote:
It seems that currently, GetAppConfigDir performs rather incosistently.
On Unix, it returns path with trailing pathdelim, on windows it returns
path with random trailing path delim (depends on which branch, see code).
What should it be then?
:)
This is exactly the reason
Could you show me the advantage of having an incompatible string
implementation in FPC 2.4, which will be out after highlander?
Boost the usage of Unicode in FPC that would boost the usage of FPC
itself. Unicode is one of the most demanded features (beside cross
platform, 64bit support, etc)
"compatible" is nonsense, since they are not compatible to any of the
roughly three preexisting ones. Descendant could be said, but I don't even
see much evidence for that. There is a superficial resemblance in the parser
model and that is about it.
At least, they're trying to answer what the us
Op Tue, 29 Jul 2008, schreef Bee:
Could you show me the advantage of having an incompatible string
implementation in FPC 2.4, which will be out after highlander?
Boost the usage of Unicode in FPC that would boost the usage of FPC itself.
Unicode is one of the most demanded features (beside
> > "compatible" is nonsense, since they are not compatible to any of the
> > roughly three preexisting ones. Descendant could be said, but I don't even
> > see much evidence for that. There is a superficial resemblance in the parser
> > model and that is about it.
>
> At least, they're trying to
55 matches
Mail list logo
