Re: [fpc-pascal] Generic String Functions
..Continuing the never ending discussion ... [ In one ore more other threads here I showed that (IMHO) it would be most sensible (and in fact not performance killing (!) ) way out of the multiple (statically defined) new String types with different encoding (with auto-conversion) to additionally support a fully dynamically encoded string type (with auto-conversion) - which needs some compiler magic - and use same as the base type for TStrings and it's siblings. ] The growing popularity of Generics might suggest to call this String encoding Generic, too, (to easily tell it from the Delphi-introduced Raw, and the dedicated encoding types). Regarding arguments for it's usefulness I came across that the Lazarus API currently forces TStrings to be UTF8 encoded while Delphi currently forces TStrings to be UTF16 encoded. IMHO the only way to prevent disastrous compatibility problems is to do TStrings being Genericencoded and with that allow for decent portability for both. -Michael ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] Announces License question
Hi, I have released some free pascal code. - *data2pas* a command line tool that generates pascal include files from a text file description. This is a tool similar to *data2inc* but using a more pascalish syntax. (GPL v3+) http://yann.merignac.free.fr/data2pas.html - *CmdLine* is a Free Pascal unit for parsing easily GNU style command line options. (LGPL v3+) http://yann.merignac.free.fr/unit-cmdline.html - *GContnrs* is a generic container collection for Free Pascal. It implements : doubly linked lists, dequeues, hash maps, hash sets, priority queues, queues, stacks, tree maps, tree sets and vectors and some algorithms (sort, shuffle, min, max, ...). (LGPL v3+) http://yann.merignac.free.fr/unit-gcontnrs.html - *UPasConf *a unit that has been designed to create configuration programs in Pascal. It allows you to create programs that mimic the famous './configure' script. It can also create GNU makefiles for your projects. (LGPL v3+) http://yann.merignac.free.fr/unit-upasconf.html All units are under LGPL v3+ but I am not sure of my choice. I want the units to be usable by anyone in any kind of projects : closed source or not, commercial or not, etc... And, I want that any change to the source of the units must be made public. Do you think the LGPL is a good choice for that goals ? Thanks (and sorry for my English) ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Announces License question
On 28/02/2014 11:11, Yann Mérignac wrote: All units are under LGPL v3+ but I am not sure of my choice. I want the units to be usable by anyone in any kind of projects : closed source or not, commercial or not, etc... And, I want that any change to the source of the units mustbe made public. Do you think the LGPL is a good choice for that goals ? Yes, that seems like a good fit to me. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Announces License question
On 28 Feb 2014, at 11:11, Yann Mérignac wrote: - *data2pas* a command line tool that generates pascal include files from a text file description. This is a tool similar to *data2inc* but using a more pascalish syntax. (GPL v3+) http://yann.merignac.free.fr/data2pas.html - *CmdLine* is a Free Pascal unit for parsing easily GNU style command line options. (LGPL v3+) http://yann.merignac.free.fr/unit-cmdline.html - *GContnrs* is a generic container collection for Free Pascal. It implements : doubly linked lists, dequeues, hash maps, hash sets, priority queues, queues, stacks, tree maps, tree sets and vectors and some algorithms (sort, shuffle, min, max, ...). (LGPL v3+) http://yann.merignac.free.fr/unit-gcontnrs.html - *UPasConf *a unit that has been designed to create configuration programs in Pascal. It allows you to create programs that mimic the famous './configure' script. It can also create GNU makefiles for your projects. (LGPL v3+) http://yann.merignac.free.fr/unit-upasconf.html All units are under LGPL v3+ but I am not sure of my choice. The first item is a program, not a unit. For that one, the license has no influence whatsoever of how the output can be used. I want the units to be usable by anyone in any kind of projects : closed source or not, commercial or not, etc... And, I want that any change to the source of the units must be made public. Do you think the LGPL is a good choice for that goals ? In theory: yes. In practice: no, because FPC doesn't support dynamic linking to the extent that is required to make this painless. You will probably want to use the GPL+linking exception (or LGPL + static linking exception, as FPC uses, but that it exactly the same thing). See https://en.wikipedia.org/wiki/GPL_linking_exception for the general explanation, and http://svn.freepascal.org/svn/fpc/trunk/rtl/COPYING.FPC for how FPC words it. Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Announces License question
On 28/02/2014 11:45, Reinier Olislagers wrote: On 28/02/2014 11:11, Yann Mérignac wrote: All units are under LGPL v3+ but I am not sure of my choice. I want the units to be usable by anyone in any kind of projects : closed source or not, commercial or not, etc... And, I want that any change to the source of the units mustbe made public. Do you think the LGPL is a good choice for that goals ? Yes, that seems like a good fit to me. Ooops: Jonas is right, please see his post... ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] How to use generics and meta class?
Em 28/02/14 03:44, Sven Barth escreveu: === code end === Currently this will print: === output begin === Bar === output end === If the compiler would now naively generate an implementation of TMyGeneric with TMyType then the result would be: === output begin === Foo === output end === This must not be. So the compiler - while it might generate an implicit TMyType implementation - must not use that implicit implemenation if the type that is specialized with implements non virtual methods itself. This is one of the restrictions. Ah, now I see. TGenericT: TType is quite different from var T: TType. Afaics the former is a placeholder for another type, the latter is a placeholder for an implementation. Thanks for sharing. Addendum: this does not exclude the compiler from trying to optimize this if the type parameter is indeed a class type. But this will be transparent for the user and will have a few restrictions. It does however not change that generics aren't full types. :/ Maybe in the near (or not so near) future, these two approaches (templates and generics like in Java) may live together? I mean: is this technically possible? FPC/Delphi generics are more templates than generics. Generics are not full types. This will not change. Got the point. Anyway current (2.6) generics meets about 80% of my needs and 2.8 sounds to meet about 98% =). Thanks for the really great work with generics! ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Announces License question
On Fri, February 28, 2014 11:45, Reinier Olislagers wrote: On 28/02/2014 11:11, Yann Mérignac wrote: All units are under LGPL v3+ but I am not sure of my choice. I want the units to be usable by anyone in any kind of projects : closed source or not, commercial or not, etc... And, I want that any change to the source of the units mustbe made public. Do you think the LGPL is a good choice for that goals ? Yes, that seems like a good fit to me. Static linking exception similar to what we use for FPC RTL and packages may be a useful extension if you want to encourage also use in commercial software. Tomas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Announces License question
Ok. So I will release new versions with licenses changed to GPL v3 + linking exception. Thanks to all. 2014-02-28 11:49 GMT+01:00 Jonas Maebe jonas.ma...@elis.ugent.be: On 28 Feb 2014, at 11:11, Yann Mérignac wrote: - *data2pas* a command line tool that generates pascal include files from a text file description. This is a tool similar to *data2inc* but using a more pascalish syntax. (GPL v3+) http://yann.merignac.free.fr/data2pas.html - *CmdLine* is a Free Pascal unit for parsing easily GNU style command line options. (LGPL v3+) http://yann.merignac.free.fr/unit-cmdline.html - *GContnrs* is a generic container collection for Free Pascal. It implements : doubly linked lists, dequeues, hash maps, hash sets, priority queues, queues, stacks, tree maps, tree sets and vectors and some algorithms (sort, shuffle, min, max, ...). (LGPL v3+) http://yann.merignac.free.fr/unit-gcontnrs.html - *UPasConf *a unit that has been designed to create configuration programs in Pascal. It allows you to create programs that mimic the famous './configure' script. It can also create GNU makefiles for your projects. (LGPL v3+) http://yann.merignac.free.fr/unit-upasconf.html All units are under LGPL v3+ but I am not sure of my choice. The first item is a program, not a unit. For that one, the license has no influence whatsoever of how the output can be used. I want the units to be usable by anyone in any kind of projects : closed source or not, commercial or not, etc... And, I want that any change to the source of the units must be made public. Do you think the LGPL is a good choice for that goals ? In theory: yes. In practice: no, because FPC doesn't support dynamic linking to the extent that is required to make this painless. You will probably want to use the GPL+linking exception (or LGPL + static linking exception, as FPC uses, but that it exactly the same thing). See https://en.wikipedia.org/wiki/GPL_linking_exception for the general explanation, and http://svn.freepascal.org/svn/fpc/trunk/rtl/COPYING.FPCfor how FPC words it. Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Property attributes
Em 27/02/14 09:34, Sven Barth escreveu: Am 27.02.2014 11:56, schrieb Joao Morais: Em 27/02/14 05:26, Sven Barth escreveu: Am 27.02.2014 01:38, schrieb Joao Morais: Hello list. What is the current status of property attributes? Some roadmap? http://wiki.freepascal.org/Property_attributes There is a branch which already supports class attributes. Property attributes (or any other kind of attributes) are not supported yet. Also they are implemented Delphi compatible (with attributes being in front of the class instead of after it). Thanks! Plans to include at least class attributes in the 2.8 roadmap? Maybe not. We are currently holding back with big features, because we want to branch 2.8/3.0 in the near future and these would only disrupt the stable state of trunk. My understanding of your comment is that property attributes is a post-2.8 feature? Yes. I don't know whether we would merge them to the next fixes branch (2.8.1/3.0.1) though. Thanks. Another point: is the proposal of the wiki the actual and post-2.8 implementation? I mean: plans to implement something like property attributes' type? Something like @Annotations =). ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] List published properties of a class
Em 09/02/14 18:05, Joao Morais escreveu: Hello list. I need to list all published properties declared in a class, iow, removing properties inherited from the parent. Up to now I am iterating typinfo.GetPropList, starting at: GetTypeData(PTypeInfo(TheClass.ClassParent.ClassInfo))^.PropCount; and it works (fpc 2.6.2). TheClass will never receive TObject. Is this the right way? Will such piece of code continue working in future versions of the rtl? Resurrecting this old message. The point is: TObject.ClassInfo is and will always be a TypeInfo pointer? If so, out of curiosity, why declare it as Pointer? What comes to mind is circular reference, layer violation, something like this. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Announces License question
In our previous episode, Yann M?rignac said: Ok. So I will release new versions with licenses changed to GPL v3 + linking exception. I would do gplv2+ + linking exception, since that makes it more compatible to FPC, and the risk on Tivoisation is that great in this case. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Generic String Functions
Am 28.02.2014 09:37 schrieb Michael Schnell mschn...@lumino.de: ..Continuing the never ending discussion ... [ In one ore more other threads here I showed that (IMHO) it would be most sensible (and in fact not performance killing (!) ) way out of the multiple (statically defined) new String types with different encoding (with auto-conversion) to additionally support a fully dynamically encoded string type (with auto-conversion) - which needs some compiler magic - and use same as the base type for TStrings and it's siblings. ] The growing popularity of Generics might suggest to call this String encoding Generic, too, (to easily tell it from the Delphi-introduced Raw, and the dedicated encoding types). Regarding arguments for it's usefulness I came across that the Lazarus API currently forces TStrings to be UTF8 encoded while Delphi currently forces TStrings to be UTF16 encoded. IMHO the only way to prevent disastrous compatibility problems is to do TStrings being Genericencoded and with that allow for decent portability for both. Problem: there is (currently) no string type that can handle ANSI, UTF-8 and UTF-16 at once. The first two are handled by AnsiString and the third by UnicodeString. And those two are not equal which would be important for overrides/overloads/inheritance. Without that your whole idea is useless. Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] How to use generics and meta class?
Am 28.02.2014 12:07 schrieb Joao Morais l...@joaomorais.com.br: Em 28/02/14 03:44, Sven Barth escreveu: === code end === Currently this will print: === output begin === Bar === output end === If the compiler would now naively generate an implementation of TMyGeneric with TMyType then the result would be: === output begin === Foo === output end === This must not be. So the compiler - while it might generate an implicit TMyType implementation - must not use that implicit implemenation if the type that is specialized with implements non virtual methods itself. This is one of the restrictions. Ah, now I see. TGenericT: TType is quite different from var T: TType. Afaics the former is a placeholder for another type, the latter is a placeholder for an implementation. Thanks for sharing. Yes, that's an important difference :) Addendum: this does not exclude the compiler from trying to optimize this if the type parameter is indeed a class type. But this will be transparent for the user and will have a few restrictions. It does however not change that generics aren't full types. :/ Maybe in the near (or not so near) future, these two approaches (templates and generics like in Java) may live together? I mean: is this technically possible? FPC/Delphi generics are more templates than generics. Generics are not full types. This will not change. Got the point. Anyway current (2.6) generics meets about 80% of my needs and 2.8 sounds to meet about 98% =). Thanks for the really great work with generics! You're welcome. I still have enough work left though ;) Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] List published properties of a class
Am 28.02.2014 12:33 schrieb Joao Morais l...@joaomorais.com.br: Em 09/02/14 18:05, Joao Morais escreveu: Hello list. I need to list all published properties declared in a class, iow, removing properties inherited from the parent. Up to now I am iterating typinfo.GetPropList, starting at: GetTypeData(PTypeInfo(TheClass.ClassParent.ClassInfo))^.PropCount; and it works (fpc 2.6.2). TheClass will never receive TObject. Is this the right way? Will such piece of code continue working in future versions of the rtl? Resurrecting this old message. The point is: TObject.ClassInfo is and will always be a TypeInfo pointer? If so, out of curiosity, why declare it as Pointer? What comes to mind is circular reference, layer violation, something like this. Yes, that is the reason. TTypeInfo (and PTypeInfo) is declared in unit typinfo, but TObject and thus ClassInfo is declared in unit system which does not use any other unit. Also it will stay like this. It would break way too much code if we'd change that. Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Announces License question
On 28 Feb 2014, at 12:44, Marco van de Voort wrote: In our previous episode, Yann M?rignac said: Ok. So I will release new versions with licenses changed to GPL v3 + linking exception. I would do gplv2+ + linking exception, since that makes it more compatible to FPC, At least all of our own source code is (L)GPL2+, so it shouldn't cause problems. Do we have package that are GPLv2 without the or later clause? and the risk on Tivoisation is that great in this case. I guess you mean not? In any case, GPLv3 also offers some protection against (or rather, offence against) software patents. Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Generic String Functions
In our previous episode, Sven Barth said: Problem: there is (currently) no string type that can handle ANSI, UTF-8 and UTF-16 at once. The first two are handled by AnsiString and the third by UnicodeString. And those two are not equal which would be important for overrides/overloads/inheritance. Without that your whole idea is useless. Moreover, will operations that use character access make sense at all if you don't know what the actual encoding is? (not only s[] but also pos,delete,insert etc). The same code can seem to behave differently because different code-paths make the same parameter have different encodings. It will require a forceencoding() function etc, which is incompatible with all current stringcode, and frustrate the general no conversion spirit which is the main advantage. And of course it is totally incompatible with Delphi. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Announces License question
In our previous episode, Jonas Maebe said: I would do gplv2+ + linking exception, since that makes it more compatible to FPC, At least all of our own source code is (L)GPL2+, so it shouldn't cause problems. Not compatible to our license, but compatible to being included in collections with uniform license like ours. Nothing legal, just a practical remark against the proliferation of licenses. A proliferation of licenses makes making collections with one such statement difficult. And specially if the difference in two such licenses is small, it is IMHO better conform to something already used. Do we have package that are GPLv2 without the or later clause? Not that I know. and the risk on Tivoisation is that great in this case. I guess you mean not? In any case, GPLv3 also offers some protection against (or rather, offence against) software patents. I know that was the intention of GPLv3, but I don't what came of it, and how practical (or limiting) it is. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Generic String Functions
In our previous episode, Michael Schnell said: Here, The Delphi model does not provide a String encoding type (and appropriate compiler magic) that can be used for that purpose (i.e. fully dynamically encoded). Hence the fpc team _might_ decide to enhance the Delphi imposed model appropriately and with that help the Lazarus team to provide a more Delphi compatible - even though OS independent - API for the LCL. I think it is better to start implementing it in a fork. A fork can move much faster and make a reconnaissance of all problems and find solutions for them, and see what you can do to improve compatibility. One the fork has a functioning Lazarus again, you will have a much better bargaining position than now while it is all paper, and some people are strongly in favor, and the others say it won't work. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Generic String Functions
Am 28.02.2014 14:16, schrieb Michael Schnell: On 02/28/2014 12:53 PM, Sven Barth wrote: Problem: there is (currently) no string type that can handle ANSI, UTF-8 and UTF-16 at once. The first two are handled by AnsiString and the third by UnicodeString. And those two are not equal which would be important for overrides/overloads/inheritance. Without that your whole idea is useless. Of course this only is relevant when New Delphi (i.e. partly dynamically encoded) Strings are introduced (I decline to use the terms AnsiString and UnicodeString due to ambiguity, unless it comes with a clear definition close by). As long as not stated differently AnsiString and UnicodeString are meant as implemented in FPC trunk. Here, The Delphi model does not provide a String encoding type (and appropriate compiler magic) that can be used for that purpose (i.e. fully dynamically encoded). Basically it does. In theory the additional record prepended to each string (wich contains the reference count among others) could be used for 1-, 2-, 4- or multi-Byte strings as it carries a ElementSize field which is currently fixed to 1 for AnsiString (even with UTF-8) and to 2 for UnicodeString (both strings use the same record layout though they are declared as different ones). Also there is the StringElementSize function which is overloaded for RawByteString and UnicodeString and which already returs the value of ElementSize. So purely in theory the current AnsiString type would already be capable enough. Also the compiler might already handle overloads correctly if we'd have a (for now hypothetical AnsiString(UTF16) (which would be equal to UnicodeString)). One of the problematic parts that already Marco mentioned is character access. A possible solution here would be to force the character size depending on the declared string type (2 for AnsiString(UTF16), 4 for AnsiString(UTF32), 1 for any 1-Byte AnsiString encoding and either 1 or 6 for UTF-8 (6 is the maximum number of Bytes that UTF-8 might encode a character with, but it's currently the maximum used is 4)) and not depending on the runtime type. The compiler would then either need to insert approbiate conversions if the runtime type does not match the declared type (for whatever reason) or the compiler would need to assume that the runtime type always matches the declared type. In the former case this might be quite some performance penalty (this could be avoided if the compiler would create approbiate inline code for detecting the runtime encoding). An open problem left would be RTTI as there currently are tkUString (for UnicodeString) and tkLString (for AnsiString) of which the second contains a codepage field while the first does not. And to keep Delphi code as much compatible as possible the compiler would then again need to handle the RTTI of a AnsiString(UTF16) differently... Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Generic String Functions
On 02/28/2014 12:53 PM, Sven Barth wrote: Problem: there is (currently) no string type that can handle ANSI, UTF-8 and UTF-16 at once. The first two are handled by AnsiString and the third by UnicodeString. And those two are not equal which would be important for overrides/overloads/inheritance. Without that your whole idea is useless. Of course this only is relevant when New Delphi (i.e. partly dynamically encoded) Strings are introduced (I decline to use the terms AnsiString and UnicodeString due to ambiguity, unless it comes with a clear definition close by). Here, The Delphi model does not provide a String encoding type (and appropriate compiler magic) that can be used for that purpose (i.e. fully dynamically encoded). Hence the fpc team _might_ decide to enhance the Delphi imposed model appropriately and with that help the Lazarus team to provide a more Delphi compatible - even though OS independent - API for the LCL. -Michael ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Generic String Functions
On 02/28/2014 01:04 PM, Marco van de Voort wrote: Moreover, will operations that use character access make sense at all if you don't know what the actual encoding is? The administrative record of each New Delphi string contains the encoding type and the byte-count for each code. So you (the compiler and the RTL) do know it. The only shortcoming in Delphi is that the handling is completely static: - if the encoding definition of the type the string is created with is not RAW, the encoding needs to be known at compile time (i.e. the encoding type is not allowed to be modified at run time) - if the encoding definition of the type the string is created with is RAW, auto-conversion from this string to a non-RAW is not done. Hence (including - but not only - for decent use on multiple OSes) an additional fully dynamically encoded type (I suggest to call the type of this Strings Generic) is necessary. (not only s[] but also pos,delete,insert etc). The same code can seem to behave differently because different code-paths make the same parameter have different encodings. I suppose that you are right. But not only the funny position numbers pos(), delete(), insert() and friends use, create a problem, but also the the String type they are defined to use does: - If using any statically encoded type for same, it is close to impossible to create decently fast programs for string manipulation (unless they by chance use the correct encoding type), as auto-conversion to and fro is invisibly introduced. - If using the suggested dynamically encoded type, we will have problems when combining strings of different types in a code snippet that calls these functions. I don't know if / how / to_what_extent compiler magic can help here (doing auto-conversion when necessary similar to when simply assigning strings of different encoding types). In the end, I feel it would be very un-desirable but might be the only easy solution to go with full Delphi compatibility and handle all strings encoding but UFT16 in a very un-decent way. This would force Lazarus to provide a (Delphi compatible) LCL-API completely done with UTF16. This completely contradicts all they did in the last few years :-) . -Michael ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Generic String Functions
Am 28.02.2014 15:01, schrieb Michael Schnell: On 02/28/2014 01:04 PM, Marco van de Voort wrote: Moreover, will operations that use character access make sense at all if you don't know what the actual encoding is? The administrative record of each New Delphi string contains the encoding type and the byte-count for each code. So you (the compiler and the RTL) do know it. The only shortcoming in Delphi is that the handling is completely static: - if the encoding definition of the type the string is created with is not RAW, the encoding needs to be known at compile time (i.e. the encoding type is not allowed to be modified at run time) It is possible as some mails a few months back have shown. If you have a function that has a RawByteString return type then you can assign that to a string of any static encoding even if the dynamic encoding is not the same (and then static and dynamic encoding of the string variable will not match, nevertheless the RTL and the compiler will handle them correctly (at least I hope so ^^). - if the encoding definition of the type the string is created with is RAW, auto-conversion from this string to a non-RAW is not done. Hence (including - but not only - for decent use on multiple OSes) an additional fully dynamically encoded type (I suggest to call the type of this Strings Generic) is necessary. The non-conversion nature of RawByteString has its use. Namely to implement the conversion mechanism of any dynamically encoded type (like the current AnsiString is) without the need to implement yet another special construct. Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Generic String Functions
In our previous episode, Michael Schnell said: Moreover, will operations that use character access make sense at all if you don't know what the actual encoding is? The administrative record of each New Delphi string contains the encoding type and the byte-count for each code. So you (the compiler and the RTL) do know it. Yes, but the point is that the programmer that writes the index into the delete() might not oversee all cases. (codepaths that can bring a string to the current point). Keeping in mind that these functions generally work at the encoding granularity level. So something that works with unicode (utf16) will fail with ansi (utf8) if it contains values that utf8 can't encode in one byte. - If using any statically encoded type for same, it is close to impossible to create decently fast programs for string manipulation (unless they by chance use the correct encoding type), as auto-conversion to and fro is invisibly introduced. Well, the trick is not to leave that to chance. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Generic String Functions
On 02/28/2014 02:26 PM, Marco van de Voort wrote: I think it is better to start implementing it in a fork. A fork can move much faster and make a reconnaissance of all problems and find solutions for them, and see what you can do to improve compatibility. One the fork has a functioning Lazarus again, you will have a much better bargaining position than now while it is all paper, and some people are strongly in favor, and the others say it won't work. I see that trying different kinds of Delphi compatibility plus OS-independence (which obviously is a contradiction in itself) makes a lot of sense for the fpc / Lazarus combination. But what do you mean by fork regarding the compiler and RTL (which would be the prerequisite for any decent LCL implementation). A) Doing a Generic (fully dynamically encoded) String type. Here, IMHO regarding the compiler a fork is not necessary, as this is a pure addition. If you don't like it, just don't create any string with that type. Defining the type of TStrings (and some other RTL introduced objects and functions would be a simple ifdef thingy. Of course the implementation of the functionality is mostly a pure addition, as well, as the actual type needs to be detected and handled appropriately (easy with TStringList, but potentially complex for stuff like TMemo, no idea (yet) with pos(), copy() and friends). B) another idea of forking on behalf of Lazarus could be to do a Delphi compatible branch with a completely UTF16 based RTL (and compiler magic) and a Lazarus compatible branch with a completely UTF8 based RTL (and compiler magic) -Michael ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Generic String Functions
On 02/28/2014 03:08 PM, Sven Barth wrote: It is possible as some mails a few months back have shown. If you have a function that has a RawByteString return type then you can assign that to a string of any static encoding even if the dynamic encoding is not the same (and then static and dynamic encoding of the string variable will not match, nevertheless the RTL and the compiler will handle them correctly (at least I hope so ^^). I don't have any Unicode Delphi so I can't test that and as far as I am informed the implementation of new Delphi strings in the fpc RTL is still a moving target. In many discussions I was told that the Delphi RAW type does not provide the features necessary to a fully dynamically encoded String, even though when I first read the online Delphi docs, I had the impression that it should. . The non-conversion nature of RawByteString has its use. I don't doubt this at all. That is why I don't suggest to modify it's behavior but to introduce yet another String encoding type. The functionality for this is already in place in the (future) RTL, only the (really small) compiler magic to call conversions when necessary needs to be added and called if a string of this type definition is to be handled. (Easy with pure assignments, as discussed in that thread pos(), copy() and friends need some more re-thinking.) -Michael ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Generic String Functions
On 02/28/2014 03:09 PM, Marco van de Voort wrote: Yes, but the point is that the programmer that writes the index into the delete() might not oversee all cases. You are absolutely right. But since Unicode is usable in Strings, a normal programmer is not really allowed to write an index in pos(), delete(), and MyString[i]. To do this a decent understanding of Unicode is necessary (this has been discussed at any length in multiple forums) The only allowable thing is to use the index returned by pos in copy() and friends on the same string. This works (mostly) as expected for any encoding. Well, the trick is not to leave that to chance. I don't understand. When using Lazarus (if it stays similar to what it is now) your strings will be UTF8. If pos() requires UTF16 you are out of luck. -Michael ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Generic String Functions
In our previous episode, Michael Schnell said: Well, the trick is not to leave that to chance. I don't understand. When using Lazarus (if it stays similar to what it is now) your strings will be UTF8. If pos() requires UTF16 you are out of luck. Fixing that in Lazarus is easier than implementing your case in the compiler. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Generic String Functions
On 02/28/2014 03:00 PM, Sven Barth wrote: As long as not stated differently AnsiString and UnicodeString are meant as implemented in FPC trunk. Can you point me to a _final_ documentation on this ? Here, The Delphi model does not provide a String encoding type (and appropriate compiler magic) that can be used for that purpose (i.e. fully dynamically encoded). Basically it does. Yep. In theory :-) Of course I know how this works (otherwise this discussion would not make any sense at all) that the implementation of the string record allows for this, but Embarcadero does not allow the users to decently take advantage of it. - non-Raw does not allow for modifying the type and code-length fields - Raw does not provide auto-conversion (seemingly for good reasons) -Michael ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Generic String Functions
On 02/28/2014 03:37 PM, Marco van de Voort wrote: Fixing that in Lazarus is easier than implementing your case in the compiler. Maybe. (Mseide shows how this can be done even without New Delphi Strings). But in many discussions I learned that the Lazarus team is not at all happy with the idea to do a UTF16 LCL (API). And IMHO a versatile compiler and RTL should be able to handle any string encoding type (that is offered to be defined) decently and not (like Delphi) to allow for defining a - say - UTF8 or European 8 Bit ANSI String and not provide the normal RTL functions in a way that allows for using it in a fast program. If multiple string types are available the user programmer should be free in choosing any of them according to the task at hand. -Michael ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Generic String Functions
In our previous episode, Michael Schnell said: I see that trying different kinds of Delphi compatibility plus OS-independence (which obviously is a contradiction in itself) makes a lot of sense for the fpc / Lazarus combination. I don't really see it. I'm not even sure if I would like it, even if there was no Delphi compatibility to consider. But what do you mean by fork regarding the compiler and RTL (which would be the prerequisite for any decent LCL implementation). Well, since the choices for FPC have been made, you were working on your own version, a bit like MSEGUI's Martin Schreiber? A) Doing a Generic (fully dynamically encoded) String type. Here, IMHO regarding the compiler a fork is not necessary, as this is a pure addition. It is necessarily, since you must show it can actually work. Since you want a decision as much as possible, I wouldn't work in a branch but in a separate fork, and just hack it to run on say Linux and Windows. Just as a proof of concept. If you have a working proof of concept it is much easier to convince people to give it a go. Much easier than with just two paragraphs of descriptions fragmented over 250 unicode discussion messages. B) another idea of forking on behalf of Lazarus could be to do a Delphi compatible branch with a completely UTF16 based RTL (and compiler magic) and a Lazarus compatible branch with a completely UTF8 based RTL (and compiler magic) single source two releases, or two source two releases? ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Generic String Functions
On 02/28/2014 04:07 PM, Marco van de Voort wrote: If you have a working proof of concept ... As this would need some (even if not much) compiler magic, I will never be able to provide something like this. Here the help of someone who understands the internal working of the compiler is necessary. If nobody is inclined to do such an enhancement, we will never see it :-( . -Michael ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Generic String Functions
On 02/28/2014 04:07 PM, Marco van de Voort wrote: a bit like MSEGUI's Martin Schreiber? No. AFAIK, MSEGUI uses the fpc compiler out of the box and only provides an alternate library and IDE. Martin did draft a new fpc-alike compiler (as discussed in his mailing list) but he declined to implement Delphi News strings of any kind. -Michael ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Generic String Functions
On 02/28/2014 04:07 PM, Marco van de Voort wrote: single source two releases, or two source two releases? Hmm. I suppose also compiler magic is affected and thus the compiler would needed to be re-compiled for either release. -Michael ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Generic String Functions
Am 28.02.2014 15:24, schrieb Michael Schnell: On 02/28/2014 03:08 PM, Sven Barth wrote: It is possible as some mails a few months back have shown. If you have a function that has a RawByteString return type then you can assign that to a string of any static encoding even if the dynamic encoding is not the same (and then static and dynamic encoding of the string variable will not match, nevertheless the RTL and the compiler will handle them correctly (at least I hope so ^^). I don't have any Unicode Delphi so I can't test that and as far as I am informed the implementation of new Delphi strings in the fpc RTL is still a moving target. The string type itself is fully functional as far as I know. There might still be a few bugs regarding Delphi compatibility here and then, but that's nothing new. In many discussions I was told that the Delphi RAW type does not provide the features necessary to a fully dynamically encoded String, even though when I first read the online Delphi docs, I had the impression that it should. . There is no special RAW type. There is only AnsiString and the RawByteString is merely a AnsiString(CP_NONE). The non-conversion nature of RawByteString has its use. I don't doubt this at all. That is why I don't suggest to modify it's behavior but to introduce yet another String encoding type. No. I would not introduce yet another string type, but try to merge the existing string types instead as they all share at least the logic/concept while not the implementation. Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Generic String Functions
Am 28.02.2014 15:42, schrieb Michael Schnell: On 02/28/2014 03:00 PM, Sven Barth wrote: As long as not stated differently AnsiString and UnicodeString are meant as implemented in FPC trunk. Can you point me to a _final_ documentation on this ? Work on final documentation will be started when 2.8/3.0 will be released. Till then wiki.freepascal.org/FPC_Unicode_Support can be considered the documentation. Please note that the non existance of a documentation does not mean that a feature is not considered final. And the new string type is working as it should, what's still left is to adjust the RTL for more Ansi-/UnicodeString awareness. Of course I know how this works (otherwise this discussion would not make any sense at all) that the implementation of the string record allows for this, but Embarcadero does not allow the users to decently take advantage of it. - non-Raw does not allow for modifying the type and code-length fields Yes, but you can always do it by converting to RawByteString: === code begin === function ChangeCodePage(aStr: RawByteString; aCodePage: TSystemCodePage): RawByteString; begin Result := aStr; SetCodePage(Result, aCodePage, False); end; var s: UTF8String; begin s := 'Hello World'; Writeln(StringCodePage(s)); s := ChangeCodePage(s, CP_ACP); Writeln(StringCodePage(s)); end. === code end === === output begin === 65001 0 === output end === Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] How to use generics and meta class?
2014-02-28 8:57 GMT-03:00 Sven Barth pascaldra...@googlemail.com: Am 28.02.2014 12:07 schrieb Joao Morais l...@joaomorais.com.br: Guys, I added your names in an TdGStorage demo: https://github.com/silvioprog/dopf/blob/master/demos/storage/demo1.lpr (y) -- Silvio Clécio My public projects - github.com/silvioprog ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] Enum scope
Hi, The FPC stable version allow to declare a new type, as private/protected/public, inside a class. So, I propose migrate enums to your own classes... why? Well, I have my own TProcess so TMyProcess inherit from TProcess. Perfectly. But I need to use some properties like: Property Options : TProcessOptions Property Priority : TProcessPriority Property StartupOptions : TStartupOptions These properties are defined in Process unit. My class is in myprocess unit (or something like that). The problem is: I can not use the enums values because they don't exists in my unit (myprocess) but if these enums were defined inside TProcess class (public type), I can use them without problem. So, what do you think about it? Regards, Marcos Douglas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Enum scope
On Fri, 28 Feb 2014 15:29:03 -0300 Marcos Douglas m...@delfire.net wrote: [...] These properties are defined in Process unit. My class is in myprocess unit (or something like that). The problem is: I can not use the enums values because they don't exists in my unit (myprocess) but if these enums were defined inside TProcess class (public type), I can use them without problem. So, what do you think about it? Enums are always public and global. For example: TMyClass = class private type MyEnums = (enum1, enum2); public e: MyEnums; end; enum1 can be used in other units. Mattias ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Enum scope
On 28.02.2014 19:59, Marcos Douglas wrote:
On Fri, Feb 28, 2014 at 3:47 PM, Mattias Gaertner
nc-gaert...@netcologne.de wrote:
On Fri, 28 Feb 2014 15:29:03 -0300
Marcos Douglas m...@delfire.net wrote:
[...]
These properties are defined in Process unit. My class is in myprocess unit
(or something like that).
The problem is: I can not use the enums values because they don't exists in
my unit (myprocess) but if these enums were defined inside TProcess class
(public type), I can use them without problem.
So, what do you think about it?
Enums are always public and global.
For example:
TMyClass = class
private
type
MyEnums = (enum1, enum2);
public
e: MyEnums;
end;
enum1 can be used in other units.
But that's what I'm talking about! :)
So if the TProcessOptions, TProcessPriority and TStartupOptions was
declared as a type inside TProcess I do not needed to import (uses)
two units (follow the example: process and myprocess) in a third unit.
I propose migrate these enums from units to be member of classes.
Sidenote: What you propose would work only if {$scopedenums on} is used
in the unit which defines the enums and in that case you'd have the
problem with backwards compatibility.
Regards,
Sven
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Enum scope
On Fri, Feb 28, 2014 at 4:22 PM, Sven Barth pascaldra...@googlemail.com wrote:
On 28.02.2014 19:59, Marcos Douglas wrote:
On Fri, Feb 28, 2014 at 3:47 PM, Mattias Gaertner
nc-gaert...@netcologne.de wrote:
On Fri, 28 Feb 2014 15:29:03 -0300
Marcos Douglas m...@delfire.net wrote:
[...]
These properties are defined in Process unit. My class is in myprocess
unit
(or something like that).
The problem is: I can not use the enums values because they don't exists
in
my unit (myprocess) but if these enums were defined inside TProcess
class
(public type), I can use them without problem.
So, what do you think about it?
Enums are always public and global.
For example:
TMyClass = class
private
type
MyEnums = (enum1, enum2);
public
e: MyEnums;
end;
enum1 can be used in other units.
But that's what I'm talking about! :)
So if the TProcessOptions, TProcessPriority and TStartupOptions was
declared as a type inside TProcess I do not needed to import (uses)
two units (follow the example: process and myprocess) in a third unit.
I propose migrate these enums from units to be member of classes.
Sidenote: What you propose would work only if {$scopedenums on} is used in
the unit which defines the enums and in that case you'd have the problem
with backwards compatibility.
Do not need {$scopedenums on}.
See example bellow. Unit1 uses Unit2 and this uses Unit3.
The problem with backwards compatibility could be resolved using {$IFDEF} IMHO.
Regards,
Marcos Douglas
=== BEGIN ===
unit Unit3;
{$mode objfpc}{$H+}
interface
uses
Classes, SysUtils;
type
TFoo = class
public type
TEnum = (fooA, fooB, fooC);
public
FValue: TEnum;
end;
implementation
end.
unit Unit2;
{$mode objfpc}{$H+}
interface
uses
Classes, SysUtils, Unit3;
type
TNewFoo = class(TFoo)
end;
implementation
end.
unit Unit1;
{$mode objfpc}{$H+}
interface
uses
Classes, SysUtils, Forms, StdCtrls,
Unit2;
type
TForm1 = class(TForm)
Button1: TButton;
procedure Button1Click(Sender: TObject);
private
public
{ public declarations }
end;
var
Form1: TForm1;
implementation
{$R *.lfm}
{ TForm1 }
procedure TForm1.Button1Click(Sender: TObject);
var
F: TNewFoo;
begin
F := TNewFoo.Create;
try
F.FValue := TNewFoo.TEnum.fooA;
finally
F.Free;
end;
end;
end.
===END===
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Announces License question
Compatibility with FPC and avoid the proliferation of licenses... 2 good arguments in favor of GPL v2+ + linking exception. I'll go that way. Thanks 2014-02-28 13:10 GMT+01:00 Marco van de Voort mar...@stack.nl: In our previous episode, Jonas Maebe said: I would do gplv2+ + linking exception, since that makes it more compatible to FPC, At least all of our own source code is (L)GPL2+, so it shouldn't cause problems. Not compatible to our license, but compatible to being included in collections with uniform license like ours. Nothing legal, just a practical remark against the proliferation of licenses. A proliferation of licenses makes making collections with one such statement difficult. And specially if the difference in two such licenses is small, it is IMHO better conform to something already used. Do we have package that are GPLv2 without the or later clause? Not that I know. and the risk on Tivoisation is that great in this case. I guess you mean not? In any case, GPLv3 also offers some protection against (or rather, offence against) software patents. I know that was the intention of GPLv3, but I don't what came of it, and how practical (or limiting) it is. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
