On Wed, Jul 30, 2008 at 6:05 PM, Daniël Mantione
[EMAIL PROTECTED] wrote:
...because all characters that need upper/lower casing are in the BMP.
Likewise, all possible thousand separators are in the BMP, so you don't need
to bother with that either.
Ah, that's so true. :-) I'm starting to
Funny that you say that about the Oxygene language. To me the language
concept and marketing screams .NET me too wannabe.
Remobj is one of the few companies that bring the cross-platform
features, and thus the promising future of CIL (aka .NET in Microsoft
speak) up to front. They, too, do
Provided that it's a lot easier to create a compiler for CIL than
creating it for multiple CPUs and OSes, IMHO, this is the way to go on
the long run. (But of course native code will widely be in use for
several years to come :) ).
If this was true, Java would have taken that market
Well, then where are the major new features of Oxygene? Where, what?
I already did rant about future and async.
If there would be much more I would already have bought it :) .
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
On Tue, Jul 29, 2008 at 5:50 PM, Daniël Mantione
[EMAIL PROTECTED] wrote:
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) in Delphi since Delphi 7 (2001?). Yet, CodeGear never
If this was true, Java would have taken that market already. There is
nothing new to that aspect of CIL, and specially with only one minor vendor
supporting it.
Basically you are right, but
- In fact Java is very widely in use (even though there are lots of
shortcomings regarding Java e.g.
On Wed, 30 Jul 2008, Graeme Geldenhuys wrote:
On Tue, Jul 29, 2008 at 5:50 PM, Daniël Mantione
[EMAIL PROTECTED] wrote:
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,
Zitat von Michael Schnell [EMAIL PROTECTED]:
If this was true, Java would have taken that market already. There is
nothing new to that aspect of CIL, and specially with only one minor vendor
supporting it.
Basically you are right, but
- In fact Java is very widely in use (even though
On Wed, Jul 30, 2008 at 10:48 AM, Michael Van Canneyt
[EMAIL PROTECTED] wrote:
But we are few, we have day jobs, and we're not being paid for any of this.
I'm in the same boat. And I did offer to extend or start writing tests
cases to help implementation. I'm not a compiler developer (I don't
On Wed, Jul 30, 2008 at 11:04 AM, Florian Klaempfl
[EMAIL PROTECTED] wrote:
We spent this time frame with making FPC multiplatform. Knowing what's
And I thank you again for it. :)
delphi.non-technical is yellow press made by users for users.
What better place to find out what users think
Marco van de Voort schrieb:
Read this and the reactions, and weep:
http://groups.google.com/group/borland.public.delphi.non-technical/browse_frm/thread/db61d19063a2f948/289008199451755a?lnk=gstq=voort+multicore#289008199451755a
I don't agree on the point that good mt support is a matter of
Marco van de Voort schrieb:
Read this and the reactions, and weep:
http://groups.google.com/group/borland.public.delphi.non-technical/browse_frm/thread/db61d19063a2f948/289008199451755a?lnk=gstq=voort+multicore#289008199451755a
I don't agree on the point that good mt support is a
I don't agree on the point that good mt support is a matter of the
framework. _Really_ good multithreading support is a matter and must
be a matter of the language as well and in several years and must be
as common as while or for loops. Currently, multithreaded programming
is like
On Wed, 30 Jul 2008, Graeme Geldenhuys wrote:
On Wed, Jul 30, 2008 at 10:48 AM, Michael Van Canneyt
[EMAIL PROTECTED] wrote:
But we are few, we have day jobs, and we're not being paid for any of this.
I'm in the same boat. And I did offer to extend or start writing tests
cases to help
Op woensdag 30-07-2008 om 11:33 uur [tijdzone +0200], schreef Florian
Klaempfl:
Marco van de Voort schrieb:
Read this and the reactions, and weep:
Op Wed, 30 Jul 2008, schreef Graeme Geldenhuys:
Does FPC have any any functions that work correctly with surrogate
pair used by UTF-16?
Likely, because I doubt FPC has routines, other than UTF-8 - UTF-16
conversion, that need to bother with surrogate pairs. I.e. the following
code is
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
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
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 -
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 limited
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
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 from
it.
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 and
[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 separators.
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
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
FPC -
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, it's
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.
So
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
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 going to be
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
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+00A0
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
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
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
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 byte
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 some
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.
___
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
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 rather than a
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
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. There is
no
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 support
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
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
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
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
Original-Nachricht
Datum: Tue, 29 Jul 2008 19:48:46 +0700
Von: Bee [EMAIL PROTECTED]
An: FPC developers\' list fpc-devel@lists.freepascal.org
Betreff: Re: [fpc-devel] Russian locale information not compatible with FPC
locale variables
Unicode is another issue. Delphi
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 object pascal
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 :) .
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 deviates
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 thing as
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
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
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 answer what
63 matches
Mail list logo
