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
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 ful
Op woensdag 30-07-2008 om 17:08 uur [tijdzone +0200], schreef Mattias
Gärtner:
>
> There is a wiki about that discussion:
> http://wiki.freepascal.org/OpenMP_support
Thanks for the link, very usefull. And I do see that (Graeme) that my
proposal is the same af that from Florian. I just hadn't rea
Function DoSomething(const astring : string) : boolean; parallel;
begin
..
end
Why not stick to the "future" / "asyc" paradigm ? The fact that it
(supposedly) is originated from .NET does not make it a bad thing. And
if anybody already knows this paradigm from other language and thus does
Zitat von Joost van der Sluis <[EMAIL PROTECTED]>:
> 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:
> > >
> > >
>
http://groups.google.com/group/borland.public.delphi.non-technical
On Wed, Jul 30, 2008 at 5:01 PM, Joost van der Sluis <[EMAIL PROTECTED]> wrote:
> Just to test some ideas/opinions. Could something like this be usefull?
>
> Function DoSomething(const astring : string) : boolean; parallel;
> begin
> ..
> end
>
> So that the 'parallel' keywords means that if you ca
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:
> >
> > http://groups.google.com/group/borland.public.delphi.non-technical/browse_frm/thread/db61d19063a2f948/289008199451755a?lnk=gst&q=voo
On Wed, 30 Jul 2008, Graeme Geldenhuys wrote:
> On Wed, Jul 30, 2008 at 1:27 PM, Michael Van Canneyt
> <[EMAIL PROTECTED]> wrote:
> >
> > This is so, and is good, but compiler support for a new string type is
> > of a different order...
>
> That I can believe... and like somebody said before, i
On Wed, Jul 30, 2008 at 1:27 PM, Michael Van Canneyt
<[EMAIL PROTECTED]> wrote:
>
> This is so, and is good, but compiler support for a new string type is
> of a different order...
That I can believe... and like somebody said before, it affects everything.
> Manpower and time are usually the pro
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
> cas
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 programmin
> 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=gst&q=voort+multicore#289008199451755a
>
> I don't agree on the point that good mt suppo
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=gst&q=voort+multicore#289008199451755a
I don't agree on the point that good mt support is a matter of 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 thi
> Graeme Geldenhuys schrieb:
> > beating Borland to the punch by about 7 years. FPC could have
> > attracted and converted more Delphi developers...
>
> Compatibility is the only way to attract Delphi developers. Just
> consider the kcl/fpgui vs. lcl case: kcl/fpgui started before the lcl
> and
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
> Zitat von Michael Schnell <[EMAIL PROTECTED]>:
>
> > - AFAIK, CIL seems to improve some of the Java shortcomings
>
> I'm curious. Has someone evidence for that?
The CIL bytecode removes the typing needed only for interpreting, and thus
might be a bit more JIT friendly, and in general the requ
Graeme Geldenhuys schrieb:
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 (20
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 (
> 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,
> >
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 )
-
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 n
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.or
> 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 a
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,
> > "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
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 the us
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)
> 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
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
> > 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
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
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 v
> > 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
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
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
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
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
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
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
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
>> 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
>
>
> 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.
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, 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
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
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
> 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
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 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 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
> 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
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
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
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
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,
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, 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
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
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 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
> 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: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
>
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
> <[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
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
> 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
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
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
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
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
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
74 matches
Mail list logo
