Re: [fpc-devel] Forwarded message about FPC status
Am 24.12.2012 07:48 schrieb Martin Schreiber mse00...@gmail.com: 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? As I already wrote there are currently no plans to change that FPC supports only ASCII identifiers. And I hope it stays that way as the other might be harder ti be fully supported on other, more exotic platforms... But of course if someone wants to change it... 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
Den 24-12-2012 07:53, Martin Schreiber skrev: 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 Hopefully not a thing :) ___ 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 Monday 24 December 2012 10:23:00 Sven Barth wrote: Am 24.12.2012 07:48 schrieb Martin Schreiber mse00...@gmail.com: 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? As I already wrote there are currently no plans to change that FPC supports only ASCII identifiers. I don't think we can trust on that. I hoped that FPC will not use cpstrnew too. So if somebody implements non ASCII identifiers because he needs a second source Delphi compiler it will be merged because the addition does not break existing code. I assume utf-8 identifiers would not be very difficult to do in compiler. Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] INCLUDESTRINGFILE patch.
On Sun, 23 Dec 2012, Den wrote: 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. ^_^ It was on my todo list for the X-mas holidays. It has been in Mantis far too long, so expect to see it applied soon :-) Michael.___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Non-ASCII identifiers (was: Re: [fpc-devel] Forwarded message about FPC status)
Martin Schreiber wrote: On Monday 24 December 2012 10:23:00 Sven Barth wrote: As I already wrote there are currently no plans to change that FPC supports only ASCII identifiers. I don't think we can trust on that. I hoped that FPC will not use cpstrnew too. So if somebody implements non ASCII identifiers because he needs a second source Delphi compiler it will be merged because the addition does not break existing code. I assume utf-8 identifiers would not be very difficult to do in compiler. But what will the rule be as to whether something's a valid identifier? Will it have to start with something known to be a letter, or something not known to be a digit or reserved character? -- 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
[fpc-devel] registry changes
Writing this from my laptop I do not currently have all the various checkouts to look at the exact changes myself. But enquiring based on the reports I have read. http://bugs.freepascal.org/view.php?id=23523 From FPC trunk r23202 log: * Include regdef.inc only if XMLREG is defined (non-Windows platforms). On Windows it is not needed since the Windows unit is included and it has all necessary declarations. Keeping duplicate declarations in regdef.inc on Windows is dangerous since it leads to out of sync problems. * Cleanup regdef.inc to contain only necessary types and constants to work with registry unit on non-Windows platforms. --- I could not find any remarks on the user changes for trunk It appears this change breaks existing units. Technically easy to fix, it complicates user code by adding a need for fidef in the uses clause, so that compiling on windows includes the windows unit (which would break compiling on none windows.) I understand that code duplication should be avoided. Given that before registry code only required one unit, and no undef, I did wonder if a simple forward declaration (as replacement) was considered, and if so, why if was not chosen. That is as an example in 2.4 the include file in unit registry defines it's own HKEY_LOCAL_MACHINE= HKEY($8002); That of course is not good, as it duplicates the define in windows, with the risk of not being updated, should the value change. But it could have defined HKEY_LOCAL_MACHINE= windows.HKEY_LOCAL_MACHINE Then the compilation of other units would not have been broken ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: Non-ASCII identifiers (was: Re: [fpc-devel] Forwarded message about FPC status)
In our previous episode, Mark Morgan Lloyd said: too. So if somebody implements non ASCII identifiers because he needs a second source Delphi compiler it will be merged because the addition does not break existing code. I assume utf-8 identifiers would not be very difficult to do in compiler. But what will the rule be as to whether something's a valid identifier? Will it have to start with something known to be a letter, or something not known to be a digit or reserved character? Afaik the latter. You specify what is not allowed rather than which are allowed. But sourcecode edited on multiple platforms might be a problem, (e.g. ligatures, denormalization and other forms of slightly different characters), this could lead to making the comparison of identifiers expensive, which is what you don't want in a compiler. But I don't know how big that problem would be. Maybe it is negiable. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: Non-ASCII identifiers (was: Re: [fpc-devel] Forwarded message about FPC status)
On 24/12/2012 12:17, Marco van de Voort wrote: In our previous episode, Mark Morgan Lloyd said: too. So if somebody implements non ASCII identifiers because he needs a second source Delphi compiler it will be merged because the addition does not break existing code. I assume utf-8 identifiers would not be very difficult to do in compiler. But what will the rule be as to whether something's a valid identifier? Will it have to start with something known to be a letter, or something not known to be a digit or reserved character? Afaik the latter. You specify what is not allowed rather than which are allowed. Hm that makes it easy to have an incomplete list, that could later become a problem half-width spaces etc..., control chars (RTL/LTR...), currently unused codepoints (that could become anything in future...) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: Non-ASCII identifiers (was: Re: [fpc-devel] Forwarded message about FPC status)
In our previous episode, Martin said: Hm that makes it easy to have an incomplete list, that could later become a problem half-width spaces etc..., control chars (RTL/LTR...), currently unused codepoints (that could become anything in future...) Still shorter than what is allowed. And I'm pretty sure Delphi does it that way, it was said during the Delphi 2009 sales presentation iirc. (when they demonstrated unicode in source and object inspector) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: Non-ASCII identifiers (was: Re: [fpc-devel] Forwarded message about FPC status)
On 24/12/12 11:22, Martin wrote: half-width spaces etc..., control chars (RTL/LTR...), currently unused codepoints (that could become anything in future...) As Marco said, the list will be smaller than the allowed list. Also the Unicode specification defines blocks or categories for code points, so that could be used too. eg: Take a look at TCharacter.IsNumeric(..) implementation. It doesn't do actual code point comparisons, it simply checks the Unicode category of the passed in code point. 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
In our previous episode, Hans-Peter Diettrich said: 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 :-( Just a quick memory dump (as said it has been 6months since issues like this were discussed in depth): It is not a blind recompile of course. Everywhere where character access is done has to be reviewed. But any FPC rtl has some 2-byte and 1-byte support, so the amount of code to be added is not that much. At least not till e.g. compiler structures like RTTI will follow. Like always with Delphi compatibility, the level of compatibility differs greatly with what you expect. Usually first the main support is added (the ability to have unicodestring as a basetype for RTL and class hierarchy), other things follow later. That is something else then being fully D2009 compatible. So initially there will probably conversions when you pass a string to units that have many stringroutines (like dateutils,strutils, sysutils, fmtbcd etc), new utility units in Delphi will be missing etc. But I hope it will be enough to allow Lazarus (and other big projects) to start working on conversion. The process then continues (with every issue discussed, checked and doublechecked) with the other remaining defects, and probably some effort will need to be made to kill excessive conversions (like on windows utf16 - utf8 - utf16), RTTI, Literals (if delphi literals are utf8, it will probably be only a matter of time till a bug is found because sb is poking with pointers in it), new delphi units etc etc. You can also imagine that just the task of checking and fixing the windows headers for all $ifdef unicode cases is daunting. (we are still fixing heaps of 64-bit issues in them, 9 years after the initial 64-bit port) The current logical next step is to start revising the OS interface to be unicode, mainly on Windows. That alone (the fact that the windows unit swaps to unicode calls by default) is a horrible incompatible change. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] mips-linux and mipsel-linux snapshots available
Nikolai Zhubr wrote: Hi Sergei and Mark, 16.12.2012 12:41, Sergei Gorelkin: [...] This was caused by insufficient alignment of Double-typed temp variables, fixed in r23146. Moreover, it appeared that function UnixToWinAge wasn't doing anything useful since year 2005, so it was removed in r23145, making FindFirst/FindNext routines somewhat faster (and able to run without FPU). Now I am able to run the big-endian MIPS compiler on QEMU. Hoping you'll be able to reproduce it, too. This is to remind you guys that if you wish to do some testing/debugging/etc on a real mips device via ssh, two debian mips boxes (big and little endian) with plenty of disk space are running here 24/7 for exactly that purpose. They are not much loaded and I can create some account(s) for you any time. Thanks Nikolai, noted with thanks. However at the moment- for reasons related to other things I've got on the boil- I'm trying to limit myself to machines that I've actually got in my museum. I've got SGI although only running IRIX at the moment, little-endian hardware remains a problem and in practical terms I'm not sure I can put very much more effort into it. -- 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] registry changes
Hi, OK. I'll add needed defines to registry unit for Windows using this method: HKEY_LOCAL_MACHINE= windows.HKEY_LOCAL_MACHINE Yury Sidorov, j...@cp-lab.com - Original Message - From: Martin To: FPC developers' list Sent: Monday, December 24, 2012 1:13 PM Subject: [fpc-devel] registry changes Writing this from my laptop I do not currently have all the various checkouts to look at the exact changes myself. But enquiring based on the reports I have read. http://bugs.freepascal.org/view.php?id=23523 From FPC trunk r23202 log: * Include regdef.inc only if XMLREG is defined (non-Windows platforms). On Windows it is not needed since the Windows unit is included and it has all necessary declarations. Keeping duplicate declarations in regdef.inc on Windows is dangerous since it leads to out of sync problems. * Cleanup regdef.inc to contain only necessary types and constants to work with registry unit on non-Windows platforms. --- I could not find any remarks on the user changes for trunk It appears this change breaks existing units. Technically easy to fix, it complicates user code by adding a need for fidef in the uses clause, so that compiling on windows includes the windows unit (which would break compiling on none windows.) I understand that code duplication should be avoided. Given that before registry code only required one unit, and no undef, I did wonder if a simple forward declaration (as replacement) was considered, and if so, why if was not chosen. That is as an example in 2.4 the include file in unit registry defines it's own HKEY_LOCAL_MACHINE= HKEY($8002); That of course is not good, as it duplicates the define in windows, with the risk of not being updated, should the value change. But it could have defined HKEY_LOCAL_MACHINE= windows.HKEY_LOCAL_MACHINE Then the compilation of other units would not have been broken ___ 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: Non-ASCII identifiers (was: Re: [fpc-devel] Forwarded message about FPC status)
On 24/12/2012 13:05, Marco van de Voort wrote: In our previous episode, Martin said: Hm that makes it easy to have an incomplete list, that could later become a problem half-width spaces etc..., control chars (RTL/LTR...), currently unused codepoints (that could become anything in future...) Still shorter than what is allowed. And I'm pretty sure Delphi does it that way, it was said during the Delphi 2009 sales presentation iirc. (when they demonstrated unicode in source and object inspector) If you use a utf8 lib, you can check attributes of each codepoint.. though that may be slower ___ 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 18:16:06 Florian Klämpfl wrote: If nobody is interested in features you need, bad luck for you, you have three possibilities: develop them yourself, pay somebody to develop them or use another compiler. BTW, I actually think about to fork Free Pascal. Not in the near future but the primary goals are defined already: - Back to the roots. - Add the necessary to build the most productive universal programming language. - Remove the not necessary. - Produce at least as good code as Delphi 7. - Compile at least as fast as Delphi 7. 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 Mon, Dec 24, 2012 at 05:19:58PM +0100, Martin Schreiber wrote: BTW, I actually think about to fork Free Pascal. Not in the near future but the primary goals are defined already: - Back to the roots. What are the roots? - Add the necessary to build the most productive universal programming language. - Remove the not necessary. Subjective, requirements differ. I assume this definition of productive and necessary will be dictated by you and drive other people away from the project. Just like e.g. your coding style has previously. - Produce at least as good code as Delphi 7. - Compile at least as fast as Delphi 7. You know that sacrifices need to be made to make a compiler cross platform and easily portable. You can't have it all. It will be a shame to see your considerable talent wasted on another project with a bus factor of approximately 1. Henry ___ 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 Monday 24 December 2012 17:45:34 Henry Vermaak wrote: On Mon, Dec 24, 2012 at 05:19:58PM +0100, Martin Schreiber wrote: BTW, I actually think about to fork Free Pascal. Not in the near future but the primary goals are defined already: - Back to the roots. What are the roots? - Add the necessary to build the most productive universal programming language. - Remove the not necessary. Subjective, requirements differ. I assume this definition of productive and necessary will be dictated by you and drive other people away from the project. Just like e.g. your coding style has previously. Yup. - Produce at least as good code as Delphi 7. - Compile at least as fast as Delphi 7. You know that sacrifices need to be made to make a compiler cross platform and easily portable. You can't have it all. We will see. It will be a shame to see your considerable talent wasted on another project with a bus factor of approximately 1. Correct, but for me an important 1. ;-) Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
