Re: [fpc-devel] Forwarded message about FPC status
Graeme Geldenhuys wrote: On 22/12/12 16:43, Marco van de Voort wrote: I think you have a wrong idea on what the core list contains. LOL. And how is anybody supposed to know what goes on - it is a PRIVATE mailing list. Which is why I suggested that a semi-formal way of taking disputes to it might be in order, /provided/ that the results were summarised for the public. I don't think that public name-calling is at all in the interest of the community of Object Pascal users as a whole, and note that I'm including both the dwindling band of classic Borland customers and the users of FPC and Lazarus in this. Many of use non-core developers have given our input with multiple solutions, to try and help the private discussions along. But I guess all of us are not knowledgeable enough people. What a nice F*** Y** to the community. Graeme, if you don't like it then consider forking the project. However, I'd suggest that if you even start along that path the prerequisite is better documentation, and to get anywhere with that you'll need to work cordially with the existing developers for the foreseeable future. Which is something that, frankly, I think you find difficult. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Forwarded message about FPC status
Am 23.12.2012 01:50, schrieb Graeme Geldenhuys: On 22/12/12 16:43, Marco van de Voort wrote: I think you have a wrong idea on what the core list contains. LOL. And how is anybody supposed to know what goes on - it is a PRIVATE mailing list. I don't think direction on unicode (or even general) came up since the last unicode discussions on fpc-devel/pascal. OK, so once again it is proven that Unicode is just not sexy enough for the core team, so it will stay stagnant for a few more years. That's unless a member ignores all discussions and does his own thing [or gets paid for the job]. As Florian likes to says so often, whoever implements it decides. Unfortunately that courtesy is not extended to non-members, What makes you think so? Of course, one does not decide if he forgets about the community approach which means implicitly: break other people's code and work as little as possible. This is indeed one of the policies of the current svn maintainers: patches should cause as little as possible regressions. because what good is a patch [of such magnitude and effort] with no chance of ever being committed. It would if you realized that community[Graeme Geldenhuys]. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Forwarded message about FPC status
On 23.12.2012 01:50, Graeme Geldenhuys wrote:
On 22/12/12 16:43, Marco van de Voort wrote:
I think you have a wrong idea on what the core list contains.
LOL. And how is anybody supposed to know what goes on - it is a PRIVATE
mailing list.
I don't think direction on unicode (or even general) came up since the last
unicode discussions on fpc-devel/pascal.
OK, so once again it is proven that Unicode is just not sexy enough
for the core team, so it will stay stagnant for a few more years. That's
unless a member ignores all discussions and does his own thing [or gets
paid for the job]. As Florian likes to says so often, whoever implements
it decides. Unfortunately that courtesy is not extended to non-members,
because what good is a patch [of such magnitude and effort] with no
chance of ever being committed. So we are at the mercy of the FPC gods.
Did you know that my addition of target NativeNT was published as patch
to the bug tracker? Did you know that I wrote patches for the cppclass
feature to get it a bit more working than before? It was only the class
helpers where I got access to a personal branch in SVN and only the
generics when I got access to trunk.
You need to show the others that they can trust you and that you mean no
harm and then they'll treat you accordingly.
The best example is this: I had problems commenting on closed/resolved
bugs which were assigned to me, so Florian simply made me from
developer to manager. It's all about trust
Well, let me just say that the idea of two RTL's is rather ridiculous
too!! You guys keep bitching about not having enough developers, so how
on earth do you think you are going to be able to maintain developing
two RTL's, patching too RTL's when bugs are reported, inform the public
to remember to mention which RTL they are using when reporting bugs,
keeps those two RTL's in sync over time etc. Yeah, it seams you guys are
sometimes not to knowledgeable either. All you are going to do is create
more work for yourselves. But hey, who are we to state the obvious.
The two RTLs isn't as difficult as you think:
=== System.System.pp begin ===
{$define USE_UNICODE}
{$include system.pp}
=== System.System.pp end ===
=== system.pp begin ===
// where the mode is set:
{$mode objfpc}
{$ifdef USE_UNICODE}
{$modeswitch UNICODESTRINGS}
{$endif}
=== system.pp end ===
The same for the other units.
Then one just needs to pay attention whether USE_UNICODE is defined or
not inside those units and write the code accordingly. I don't say it's
a pencake, but it isn't ridiculous and the only approach that is
really viable for us as - as you said - we only have so much developers.
Regards,
Sven
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Forwarded message about FPC status
On Sun, 23 Dec 2012, Graeme Geldenhuys wrote: On 22/12/12 16:43, Marco van de Voort wrote: I think you have a wrong idea on what the core list contains. LOL. And how is anybody supposed to know what goes on - it is a PRIVATE mailing list. No, but I think you hugely overestimate what goes on in that list. It's simply a list for some highly technical discussions with people who know how things work in the compiler and RTL. It's not a list where we plot and scheme. I don't think direction on unicode (or even general) came up since the last unicode discussions on fpc-devel/pascal. OK, so once again it is proven that Unicode is just not sexy enough for the core team, so it will stay stagnant for a few more years. No, this is not so. It is really a matter of time. I think people underestimate the impact of the implementation. There are almost 1500 units, which potentially need checking and/or changing. The task is simply daunting. And that the prospect of 2 RTLs is not appealing is something we know, but it's either that or throw overboard backwards compatibility. The Delphi engineers have chosen the latter. It has cost my company lots of time and money to digest that. You yourself are affected by this in tiOPF: Version 3 vs. Version 2 ? Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Forwarded message about FPC status
On Sun, 23 Dec 2012, Sven Barth wrote: to remember to mention which RTL they are using when reporting bugs, keeps those two RTL's in sync over time etc. Yeah, it seams you guys are sometimes not to knowledgeable either. All you are going to do is create more work for yourselves. But hey, who are we to state the obvious. The two RTLs isn't as difficult as you think: Hey, don't minimalize the work I will do ;-) Sven is right about how we'll deal with it. The real work is dealing with the consequences of this apparently little change. As he writes: Then one just needs to pay attention whether USE_UNICODE is defined or not inside those units and write the code accordingly. And then go over all packages to see if all still compiles/works. for example the DB units may prove to be fun, as they mixe low with high-level code. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Forwarded message about FPC status
IMO, I wouldn't support wide-character (UnicodeString) strings for anything new. In the beginning the wide-character string had the advantage of being able to represent all characters with 2 bytes, but this is no longer the case. I would switch to UTF-8 instead and keep characters 1 byte long. A switch to UTF-8 only affects a small amount of the code-base, and doesn't break string references. In fact, I introduced UTF-8 in my OS recently, and it was easy to do. So not supporting wide-character strings does not mean you must keep an old ansi state. Leif Ekblad - Original Message - From: Hans-Peter Diettrich drdiettri...@aol.com To: FPC developers' list fpc-devel@lists.freepascal.org Sent: Sunday, December 23, 2012 5:49 AM Subject: Re: [fpc-devel] Forwarded message about FPC status Graeme Geldenhuys schrieb: Well, let me just say that the idea of two RTL's is rather ridiculous too!! It's not different from Delphi, where the introduction of UnicodeString required a renewed RTL, VCL and IDE. Who should do the same for FPC and Lazarus, and tell the users that they either have to stay with an old (frozen) Ansi release, or must upgrade all their code and component libraries to the new strings, RTL and LCL? IMO a typical loose-loose situation :-( Anyway, I can see where this thread is heading... just another waist of time. So I'll stop here. Yeah DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Forwarded message about FPC status
On Sun, 23 Dec 2012, Hans-Peter Diettrich wrote: Graeme Geldenhuys schrieb: Well, let me just say that the idea of two RTL's is rather ridiculous too!! It's not different from Delphi, where the introduction of UnicodeString required a renewed RTL, VCL and IDE. Who should do the same for FPC and Lazarus, and tell the users that they either have to stay with an old (frozen) Ansi release, or must upgrade all their code and component libraries to the new strings, RTL and LCL? IMO a typical loose-loose situation :-( ? No, the old RTL will remain maintained. It's the same codebase, just recompiled. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Forwarded message about FPC status
On 23.12.2012 11:11, Michael Van Canneyt wrote: On Sun, 23 Dec 2012, Sven Barth wrote: to remember to mention which RTL they are using when reporting bugs, keeps those two RTL's in sync over time etc. Yeah, it seams you guys are sometimes not to knowledgeable either. All you are going to do is create more work for yourselves. But hey, who are we to state the obvious. The two RTLs isn't as difficult as you think: Hey, don't minimalize the work I will do ;-) Sorry. I just couldn't let Graeme's ridiculous stand around uncommented :) Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Forwarded message about FPC status
On Sunday 23 December 2012 11:12:42 Leif Ekblad wrote: IMO, I wouldn't support wide-character (UnicodeString) strings for anything new. I don't like to read that. ;-) Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Forwarded message about FPC status
Leif Ekblad wrote: IMO, I wouldn't support wide-character (UnicodeString) strings for anything new. In the beginning the wide-character string had the advantage of being able to represent all characters with 2 bytes, but this is no longer the case. I would switch to UTF-8 instead and keep characters 1 byte long. A switch to UTF-8 only affects a small amount of the code-base, and doesn't break string references. UTF-8 is fine for external representation, and for code that's near it. After all, it's merely a form of compression in the same way that HTTP etc. uses compression for content. I think your point about two bytes now being insufficient to represent all possible Unicode codepoints is valid, but since things like expression parsing are made much more efficient by being able to iterate an array that's an argument for moving to a wider internal representation- not a narrower one. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Forwarded message about FPC status
In our previous episode, Graeme Geldenhuys said: OK, so once again it is proven that Unicode is just not sexy enough for the core team, so it will stay stagnant for a few more years. No. Simply getting older. That's unless a member ignores all discussions and does his own thing [or gets paid for the job]. As Florian likes to says so often, whoever implements it decides. Unfortunately that courtesy is not extended to non-members, because what good is a patch [of such magnitude and effort] with no chance of ever being committed. So we are at the mercy of the FPC gods. No. Core members have some freedom in doing their own thing because of a proven track record, and the knowledge they will generally see a feature or a development to the end. And indeed, external patches and committers first need to prove themselves. But there are many precedents (like Giuliano doing the resource strings), and committers are being added all the time. There probably near an handful of committers who are newer to the project than you. More if you count db-core. But then you have to work within the team, and respect some traditions and sentiments. And if there is one thing I hope others get from this discussion is that you and Martin never got that. But at least Martin _tried_ during the 2.2.2 tcomponent rewrite. Same goes for Mr. Schnell. Many of use non-core developers have given our input with multiple solutions, to try and help the private discussions along. I haven't seen actual input. Mostly I only have seen some simplistic outlines of radical new solutions that weren't fleshed out enough to fill the backside of a beercoaster. And most of them were thrown in together with some anti-Delphi sentiment. I have never even seen serious attempts from each one of you (like categorizing the objections, adapting to it, keeping documentation or points lists). (for the unicode part at least. The 2.2.2 work by Martin was certainly valued) But I guess all of us are not knowledgeable enough people. I wouldn't say that. But the two of you have the problem you always choose radical solutions, don't have a history of working on core, never done major projects inside What a nice F*** Y** to the community. So basically you just go on bullying in the maillists till you get a carte blanche up front. Well, IT WON'T HAPPEN. I dare you to bring up one piece of proposal that is detailed, consistent, and mustn't be extracted from some maillist discussion, and that shows some signs that criticism on it was processed. Well, let me just say that the idea of two RTL's is rather ridiculous too!! It was my idea actually, to repair the worst problem with delphi compatibility; the fact that Delphi broke backwards compatibility. But I abandonned it, because there seemed to be little support, and people kept believing an overload here and there would solve the problem. IOW there is no acceptance of the fact that the default stringtype is much more a global change than a per unit change. So in spring I gave up, and am now in favour of a 100% delphi compatible utf16 solution, compatibility break included. (maintain 2.6.x a bit longer though, if people care) You guys keep bitching about not having enough developers, so how on earth do you think you are going to be able to maintain developing two RTL's, patching too RTL's when bugs are reported Again you show your lack of knowledge. It _was_ about two releases built for every target from a single codebase. One 1-byte as default, one 2-byte. I/we hoped we could polish away the different 1-byte codepages away in the RTL initialization. (so the 1-byte RTL could be used for both the old Delphi 1-byte as one where it is hard utf8. There are some problems with stdio there though) But that means one codebase compiled twice (once for 1-byte, one for twobyte), only with different default types, so that inheriting methods with string types keep working. inform the public to remember to mention which RTL they are using when reporting bugs, keeps those two RTL's in sync over time etc. It is that, or rewrite it. Note that originally the two RTL solution was a temporary solution, to allow Lazarus to gradually change from manual to compiler supported unicode types. (and thus not stick to an old release for an extended period of time). I then still assumed that over time on windows the 1-byte one would disappear and on *nix the two byte one. Only when protests came, it became somewhat permanent. Yeah, it seams you guys are sometimes not to knowledgeable either. All you are going to do is create more work for yourselves. But hey, who are we to state the obvious. This message is a perfect example how you let yourself guide by sentiment. You seem to have started to believe your own advocatism, and think it is evil core that is holding you back, rather than the fact that doing a few minor bugs and spelling corrections in the docs will not give you carte blanche up
Re: [fpc-devel] Forwarded message about FPC status
In our previous episode, Leif Ekblad said: all characters with 2 bytes, but this is no longer the case. I would switch to UTF-8 instead and keep characters 1 byte long. A switch to UTF-8 only affects a small amount of the code-base, and doesn't break string references. Any solution will need a complete check. Since old code will probably store multiple encodings in the ansistring type that must be checked. See e.g. the work done on Zeos by Michael Hiergeist. That goes both for the case that the default type is 1-byte and 2-byte. So that is appearances only (ah, they are both onebyte, so not much will change). Any failure to do that will result in an infinite adding (and maintaining) of ad hoc conversions. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Forwarded message about FPC status
On 23/12/12 10:13, Michael Van Canneyt wrote: ? No, the old RTL will remain maintained. It's the same codebase, just recompiled. It was impossible to deduce that from your earlier reply http://www.mail-archive.com/fpc-devel@lists.freepascal.org/msg27659.html With the new information at hand, it seems a lot more manageable than I first envisioned. Regards, - Graeme - ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Forwarded message about FPC status
On Sun, 23 Dec 2012, Graeme Geldenhuys wrote: On 23/12/12 10:13, Michael Van Canneyt wrote: ? No, the old RTL will remain maintained. It's the same codebase, just recompiled. It was impossible to deduce that from your earlier reply http://www.mail-archive.com/fpc-devel@lists.freepascal.org/msg27659.html Correct. With the new information at hand, it seems a lot more manageable than I first envisioned. I sincerely hope so, given the time constraints :-) Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Forwarded message about FPC status
Sven Barth wrote: Did you know that my addition of target NativeNT was published as patch to the bug tracker? Did you know that I wrote patches for the cppclass feature to get it a bit more working than before? It was only the class helpers where I got access to a personal branch in SVN and only the generics when I got access to trunk. Obviously, once somebody submits a patch it's there for anybody to consult and use. So people who are into vanity publication shouldn't feel left out: if it's good, the community will read it :-) I think it's a pity though that, particularly once an issue is closed, it can be difficult to find the attached discussion etc. Some way of finding all patches which have been submitted against a particular unit could be useful, since whether accepted or not the discussion could be enlightening and in some cases rejected code could be a useful starting point if somebody later has a related problem. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Forwarded message about FPC status
On Friday 21 December 2012 13:26:12 Michael Van Canneyt wrote: After that there will be 2 RTLs: 1. The classical RTL, compatible with what you have now. 2. The unicode-string RTL which will use the namespaces of Delphi. Do you know how RTTI will be encoded? Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Forwarded message about FPC status
On 23.12.2012 16:58, Martin Schreiber wrote: On Friday 21 December 2012 13:26:12 Michael Van Canneyt wrote: After that there will be 2 RTLs: 1. The classical RTL, compatible with what you have now. 2. The unicode-string RTL which will use the namespaces of Delphi. Do you know how RTTI will be encoded? The RTTI will stay ASCII as we (at least as far as I know) don't plan to extend the compiler to allow non-ASCII identifiers. For accessing property values the same applies as for any other unit. If you use unit typinfo the unit will use AnsiString parameters and System.TypInfo will use UnicodeString parameters (at least for those methods where the parameter is just a String). Internally then the parameters need to be converted accordingly of course. Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Forwarded message about FPC status
On Sun, 23 Dec 2012, Martin Schreiber wrote: On Friday 21 December 2012 13:26:12 Michael Van Canneyt wrote: After that there will be 2 RTLs: 1. The classical RTL, compatible with what you have now. 2. The unicode-string RTL which will use the namespaces of Delphi. Do you know how RTTI will be encoded? I would guess short/ansistrings, since pascal identifiers must be a subset of ASCII anyway. It makes no sense to start using Unicode here. The extended attributes (recently implemented by Joost) may be an exception, I'll need to consult with Joost on that. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Forwarded message about FPC status
On 23.12.2012 17:01, Michael Van Canneyt wrote: On Sun, 23 Dec 2012, Martin Schreiber wrote: On Friday 21 December 2012 13:26:12 Michael Van Canneyt wrote: After that there will be 2 RTLs: 1. The classical RTL, compatible with what you have now. 2. The unicode-string RTL which will use the namespaces of Delphi. Do you know how RTTI will be encoded? I would guess short/ansistrings, since pascal identifiers must be a subset of ASCII anyway. It makes no sense to start using Unicode here. The extended attributes (recently implemented by Joost) may be an exception, I'll need to consult with Joost on that. Just in case: they are not in trunk yet, but only a branch to simplyfy review through other core devs. Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Forwarded message about FPC status
In our previous episode, Michael Van Canneyt said: Do you know how RTTI will be encoded? I would guess short/ansistrings, since pascal identifiers must be a subset of ASCII anyway. Not Delphi 2009+ btw, which allow UTF8 identifiers. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Forwarded message about FPC status
Leif Ekblad schrieb: IMO, I wouldn't support wide-character (UnicodeString) strings for anything new. In the beginning the wide-character string had the advantage of being able to represent all characters with 2 bytes, but this is no longer the case. I would switch to UTF-8 instead and keep characters 1 byte long. A switch to UTF-8 only affects a small amount of the code-base, and doesn't break string references. That's how Unicode currently is handled, e.g. in Lazarus, and the mix of codepages, e.g. for filenames, is a source of eternal trouble :-( I'd be happy with AnsiStrings with an Encoding, but a good implementation would require UnicodeStrings for the codepage conversion. DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Forwarded message about FPC status
Michael Van Canneyt schrieb: Well, let me just say that the idea of two RTL's is rather ridiculous too!! It's not different from Delphi, where the introduction of UnicodeString required a renewed RTL, VCL and IDE. Who should do the same for FPC and Lazarus, and tell the users that they either have to stay with an old (frozen) Ansi release, or must upgrade all their code and component libraries to the new strings, RTL and LCL? IMO a typical loose-loose situation :-( ? No, the old RTL will remain maintained. It's the same codebase, just recompiled. Sorry, I doubt that it is so easy :-( DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] INCLUDESTRINGFILE patch.
Hi all, I must say, it is actually quite fun to be a part of the FPC Developers mailing list, I don't know why I didn't join sooner. Quite interesting conversations and ideas, a little bit of bickering but very understanding people in general, I like it. I want to add my two cents before continuing to the point of this email: - I do like the FPC Community development style. This means that if I want a feature I can add it myself, which I've done. All it takes is a proposal, some others come in with similar experience with Pascal and recommend a few fair changes which all makes sense. - Florian is correct. It's quite easy to make a compiler. If you need it, just build it. I've made a Virtual Compiler of a programming language I invented in the past, which had it's own Virtual Runtime (executed with Assembly of course) for FUN. It really isn't that hard. The one difference is, with Free Pascal, you get to be a part of a group which is fun. Now down to the actual point of the email: -- May I get my patch here ( http://bugs.freepascal.org/view.php?id=21848) approved and in trunk? I've been using it in 2.6.x and 2.7.x for awhile now and it works quite nicely. I did the INCLUDESTRINGFILE as requested. ^_^ Anyway, I must say I love the targetandroid branch so far. I've got my Project working using Google's libandroid_native_app_glue.a, and my Game Engine works nicely on Linux/Android (with setup for Windows and iPhone coming soon). Keep up the great work everyone. Can't wait to see targetandroid merged with trunk! - Dennis Fehr ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Forwarded message about FPC status
On Sunday 23 December 2012 17:44:53 Marco van de Voort wrote: In our previous episode, Michael Van Canneyt said: Do you know how RTTI will be encoded? I would guess short/ansistrings, since pascal identifiers must be a subset of ASCII anyway. Not Delphi 2009+ btw, which allow UTF8 identifiers. What will FPC do? Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
