Re: [fpc-devel] UTF8 RTL
On 11/23/2014 04:31 PM, Michael Van Canneyt wrote: What about RTL with UTF8 as default? I am nearly done with the would-be designdocument Wiki text, you seemed to want to see done on a suggestion for an extension of the string type variants, that allow for e.g. (1) TStrings siblings and (2) GUI libraries to work for all string encoding brands without unnecessary conversions. I'll extend the examples to the RTL... -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] UTF8 RTL
On 11/23/2014 05:28 PM, Marco van de Voort wrote: I meant in the way Mattias proposed, continueing making the default string type utf8 on Windows. As with Windows, the OS requires API access with UTF-16 encoded strings this would force lots of auto-conversions, not only in the RTL but with any GUI Library, as well. Same would be true for making the default string type utf16 (or whatever) on Linux. OTOH using different default string types on different platforms auks for severe compatibility problems when trying to do portable programs. Catch 22 :-( . (I myself vote for killing the type String completely and allow/force the user to do a Type definition for String himself that is used in his code, e.g. in a central unit.) -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] UTF8 RTL
On Mon, 24 Nov 2014, Michael Schnell wrote: On 11/23/2014 05:28 PM, Marco van de Voort wrote: I meant in the way Mattias proposed, continueing making the default string type utf8 on Windows. As with Windows, the OS requires API access with UTF-16 encoded strings this would force lots of auto-conversions, not only in the RTL but with any GUI Library, as well. Same would be true for making the default string type utf16 (or whatever) on Linux. OTOH using different default string types on different platforms auks for severe compatibility problems when trying to do portable programs. Catch 22 :-( . (I myself vote for killing the type String completely and allow/force the user to do a Type definition for String himself that is used in his code, e.g. in a central unit.) How do you reconcile this with the fact that pascal should be easy, and it should be usable for teaching ? In my personal experience, 99% of people really do not care or even know about encodings. The reason is quite simple: lots of programs are written in 1 language. Let's not get carried away, please... keep it simple. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] UTF8 RTL
On 11/24/2014 10:26 AM, Michael Van Canneyt wrote: How do you reconcile this with the fact that pascal should be easy, and it should be usable for teaching ? .. Let's not get carried away, please... keep it simple. I do know that this is a decent argument That is why I put my text in brackets with an I myself vote for Maybe a way to allow the user to define the project-wide default encoding branding for the unqualified type String can be invented (e.g. OS-Default if not explicitly set) -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] UTF8 RTL
On Sun, 23 Nov 2014 18:57:33 +0100 Jonas Maebe jonas.ma...@elis.ugent.be wrote: On 23/11/14 17:23, Mattias Gaertner wrote: [...] Maybe we need another Default*CodePage variable which indicates the real system code page... +1 I also want to update the UTF-8 wiki pages. For example If you use the insert name here then For this I need a short name. If you use FPC 2.7.1 or later then ... I meant something short for FPC 2.7.1+ with SetMultiByteConversionCodePage(CP_UTF8); SetMultiByteRTLFileSystemCodePage(CP_UTF8); Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] UTF8 RTL
On 11/24/2014 10:41 AM, Michael Schnell wrote: Maybe a way to allow the user to define the project-wide default encoding branding for the unqualified type String can be invented (e.g. OS-Default if not explicitly set) Obviously this asks for a versatile String type (not existing in Delphi) for the interface of any code that is accessed by but not included in the user project. I'll post the wiki paper on this tomorrow. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] UTF8 RTL
On Sun, 23 Nov 2014 17:42:06 +0100 (CET) mar...@stack.nl (Marco van de Voort) wrote: [...] And the 2-byte unicode version exists, in unit uuchar. (the objpas of $mode delphiunicode). For now, simply make a utf8 wrapper that returns an utf8string. At the moment uuchar ParamStr only contains a typecast: if (Param=0) then Paramstr:=System.Paramstr(0) else if (Param0) and (Paramargc) then paramstr:=UnicodeString(Argv[Param]) else paramstr:=''; Unit LazUTF8 contains a procedure SetupCommandlineParametersWide, that uses GetCommandLineW and creates an ArgW array, similar to the Argv array. Should I adapt that for uuchar? Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] UTF8 RTL
Mattias Gaertner wrote on ma, 24 nov 2014: On Sun, 23 Nov 2014 17:42:06 +0100 (CET) At the moment uuchar ParamStr only contains a typecast: if (Param=0) then Paramstr:=System.Paramstr(0) else if (Param0) and (Paramargc) then paramstr:=UnicodeString(Argv[Param]) else paramstr:=''; Unit LazUTF8 contains a procedure SetupCommandlineParametersWide, that uses GetCommandLineW and creates an ArgW array, similar to the Argv array. Should I adapt that for uuchar? Probably, yes. However: * since we're close to branching/releasing 2.8, I am not very much in favour of still modifying core RTL routines like this for inclusion in 2.8 (this also goes for the defaultformatsettings related patch you posted to the bug tracker). I understand that this will make it harder to use the current RTL with Lazarus, but that can be improved for 2.8.2 yet. It's more important (to me) that what's there is stable, than supporting everything but the kitchen sink and having annoying bugs. * make functionality codepag-aware should be done for all platforms at the same time, otherwise it will become impossible to write cross-platform programs that have similar behaviour everywhere (and the list at http://wiki.freepascal.org/FPC_Unicode_support#RTL_changes will become unreadable, just like the documentation). In general you need a specific implementation for Windows and for Unix, and for all other platforms (which don't have codepage support yet) it's a mechanical change that is more or less identical. See the commits to the cpstrrtl branch for examples. Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] UTF8 RTL
On Mon, 24 Nov 2014 15:25:00 +0100 Jonas Maebe jonas.ma...@elis.ugent.be wrote: [...] Probably, yes. However: * since we're close to branching/releasing 2.8, I am not very much in favour of still modifying core RTL routines like this for inclusion in 2.8 (this also goes for the defaultformatsettings related patch you posted to the bug tracker). I understand that this will make it harder to use the current RTL with Lazarus, but that can be improved for 2.8.2 yet. It's more important (to me) that what's there is stable, than supporting everything but the kitchen sink and having annoying bugs. I guessed so. No problem. I can add workarounds for these issues in the Lazarus code. * make functionality codepag-aware should be done for all platforms at the same time, otherwise it will become impossible to write cross-platform programs that have similar behaviour everywhere (and the list at http://wiki.freepascal.org/FPC_Unicode_support#RTL_changes will become unreadable, just like the documentation). In general you need a specific implementation for Windows and for Unix, and for all other platforms (which don't have codepage support yet) it's a mechanical change that is more or less identical. See the commits to the cpstrrtl branch for examples. Ok. Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] Codepage aware RTL
Hi, The page about FPC Unicode support mentions what has already been updated to preserve character data. http://wiki.freepascal.org/FPC_Unicode_support#RTL_changes Is there already a page about what has not (yet) been updated aka does not work with all code pages? Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Codepage aware RTL
On 24/11/14 18:46, Mattias Gaertner wrote: The page about FPC Unicode support mentions what has already been updated to preserve character data. http://wiki.freepascal.org/FPC_Unicode_support#RTL_changes Is there already a page about what has not (yet) been updated aka does not work with all code pages? As that page mentions, it's an exhaustive list. Hence, nothing else has been updated (other than the primitive string functions such as insert/copy/delete/setstring, and standard I/O such as read/write/readstr/writestr). Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] IComparer vs CompareFunc
Hi, I am trying to have some code that uses generics to compile under Delphi and under FPC (uses fgl) In Delphi I pass IComparerT and in FPC TCompareFuncT IComparerT is an object and I can create it with some state that compare method can use :) In FPC I should pass function: TCompareFunc = function(const Item1, Item2: T): Integer; And I am not sure where I can add my state information that compare will use - it is not and object function :( Any help will be appreciated! Thanks, Gennady ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] What is the status of fpc generics.collections.
Hi, I have found the old announcement about fpc-generics-collections, but all links are broken... What is the status of this project? Is it still downloadable? Thank you, Gennady [fpc devel] Library announcement: Generics.Collections https://www.mail-archive.com/search?l=fpc-devel@lists.freepascal.orgq=subject:%22%5Bfpc-devel%5D+Library+announcement%3A+Generics.Collections%22 Maciej Izak https://www.mail-archive.com/search?l=fpc-devel@lists.freepascal.orgq=from:%22Maciej+Izak%22 Wed, 22 May 2013 12:45:20 -0700 https://www.mail-archive.com/search?l=fpc-devel@lists.freepascal.orgq=date:20130522 Hi Free Pascal community! I'm pleased to announce the generic library, compatible with Delphi Generics.Collections (almost ;) ). Homepage https://code.google.com/p/fpc-generics-collections/ SVN http://fpc-generics-collections.googlecode.com/svn/trunk/ === modules === Generics.Defaults Generics.Collections Generics.Helpers Generics.Hashes === compatible classes === TEnumeratorT TEnumerableT TListT TQueueT TStackT TDictionaryTKey, TValue TObjectListT: TObject TObjectStackT: TObject TObjectDictionaryTKey, TValue === renamed (because compiler limations/bug) === TArrayHelperT instead of TArrayT === additional classes === TDictionaryTKey, TValue, TProbeSequence, THash, THashFactory TObjectDictionaryTKey, TValue, TProbeSequence, THash, THashFactory TKey - key, TValue - value, THashFactory - hash factory :) TProbeSequence - TProbeSequence is special record for open addresing. To choose from a predefined: TLinearProbing, TQuadraticProbing, TDoubleHashing, TFastLinearProbing, TFastQuadraticProbing, TFastDoubleHashing (fast version is without mod) more info at http://en.wikipedia.org/wiki/Open_addressing THash - type for hash (to reduce size of dictionary - can be UInt8, UInt16, UInt32 etc.) For example, Delphi TDictionary version in this library is defined as: TDictionaryTKey, TValue = class(TDictionaryTKey, TValue, TFastLinearProbing, UInt32, TDelphiHashFactory); TDictionaryListTKey, TValue, TIndex, THash, THashFactory class, that combines a TList and TDictionary TKey - key, TValue - value, THashFactory - hash factory :) TIndex - type for index (to reduce size of dictionary - can be UInt8, UInt16, UInt32 etc.) THash - type for hash (to reduce size of dictionary - can be UInt8, UInt16, UInt32 etc.) Similar to TList, TDictionary and TDictionaryList, but uses normal operators instead of IEqualityComparer. TFastList TFastDictionary TFastDictionaryList TFastArrayHelperT - similar rules as above === not implemented === TThreadedQueueT === FAQ === 1. How to use record as Key or Value in dictionary? You need to wait for some compiler magic ( system functions GetReferenceToValue and GetValueSize described bolow) or add two methods to record: TRecord = record (* ... *) function GetValueSize: Integer; inline; function GetReferenceToValue: Pointer; inline; end; 2. How to use Pointer or some custom type as Key or Value in dictionary? You need to wait for some compiler magic ( system functions GetReferenceToValue and GetValueSize described bolow) or use TValueHelper: uses Generics.Collections, Generics.Helpers; (* ... *) type TValueHelperPointer = TValueHelperPointer; var d: TDictionaryTValueHelperPointer, string; begin (* ... *) d.Add(nil, 'foo'); === TODO === Comparer from Generics.Defaults can be optimized. I have no knowledge of FPC compiler design, so i need a little help... First thing : To finish my work I need critical compiler magic functions/feature. At first look mayby there is no sense for this functions but during work on Generic library it's necessary: function GetReferenceToValue(Value: T): Pointer; // for string types return @s[1] or nil for empty string for Int32 return @i etc. returns a reference to the value, as measured by human/programmer function GetValueSize(Value: T): Integer; // for string types return Length(s), for Int32 returs 4 etc. This functions should be implemented as operators (like Inc, Dec operators). There is half-workaround/cripled solution as record/type helpers (module Generics.Helpers). Don't work for custom strings, and for custom basic types like: type MyStr = type string; type MyInt = type Int32; Second thing: Bugs. Look at Critical - fix is needed to perform compatibility with Delphi and proper work. http://bugs.freepascal.org/view.php?id=24283 (CRITICAL! Very Important!) http://bugs.freepascal.org/view.php?id=24282 (CRITICAL! Very Important!) http://bugs.freepascal.org/view.php?id=24254 (CRITICAL! for TArray.SortT) http://bugs.freepascal.org/view.php?id=24287 (Very Important!) http://bugs.freepascal.org/view.php?id=24072 (Very Important!)
Re: [fpc-devel] Codepage aware RTL
In our previous episode, Jonas Maebe said: Is there already a page about what has not (yet) been updated aka does not work with all code pages? As that page mentions, it's an exhaustive list. Hence, nothing else has been updated (other than the primitive string functions such as insert/copy/delete/setstring, and standard I/O such as read/write/readstr/writestr). From what I remember from an earlier test is that std I/O will fail because literals are written with shortstr in some cases which isn't codepage aware. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Codepage aware RTL
On Mon, 24 Nov 2014 23:24:59 +0100 (CET) mar...@stack.nl (Marco van de Voort) wrote: [...] From what I remember from an earlier test is that std I/O will fail because literals are written with shortstr in some cases which isn't codepage aware. Do you remember which function? Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Codepage aware RTL
In our previous episode, Mattias Gaertner said:
mar...@stack.nl (Marco van de Voort) wrote:
[...]
From what I remember from an earlier test is that std I/O will fail because
literals are written with shortstr in some cases which isn't codepage aware.
Do you remember which function?
look at asm of
{$mode delphi}
const xx = 'bla';
begin
writeln(xx);
end.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Codepage aware RTL
In our previous episode, Mattias Gaertner said: [...] From what I remember from an earlier test is that std I/O will fail because literals are written with shortstr in some cases which isn't codepage aware. Do you remember which function? Never mind. That was without setcodepage I guess, since that determines the default encoding, so it should be ok. IOW if you can get the literals in the right encoding it should work. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] Implicit Transactions Postgres
Found this bug report from 2010 on using implicit transactions in PostgreSQL. As far as I can tell nothing has happened since. Using the TSQLTransaction.Action setting looks like a good approach to implementing implicit transactions. It would mean warning users about setting action as it currently does nothing and is likely ignored by many programmers. http://bugs.freepascal.org/view.php?id=17713 There is another reason to use implicit transactions. When creating or dropping a database the query must be run in a implicit transaction. Currently createDB and dropDB use implicit transactions but do not allow for options beyond the required database name. Implementing implicit transactions will compliment the transaction patch from Michael. His patch allows automatically opened transactions to be closed without closing datasets which allows for user managed transaction handling. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] can't build trunk for x86_64-linux (suse-64)
suse-32 builds fine though ... Anything obvious I have missed? Thanks, Gennady Start compiling package gdbint for target x86_64-linux. File libgdb.a not found Compiling gdbint/src/gdbint.pp Compiling gdbint/src/gdbcon.pp Compiling gdbint/src/gdbver.pp Linking gdbint/bin/x86_64-linux/gdbver The installer encountered the following error: External command /home/agranov/fpc/compiler/ppcx64 -Tlinux -FEgdbint/bin/x86_64-linux -FUgdbint/units/x86_64-linux/ -Fu/home/agranov/fpc/rtl/units/x86_64-linux/ -Figdbint/src -Fl/usr/lib64/gcc/x86_64-suse-linux/4.8 -Ur -Xs -O2 -n -Fu/home/agranov/fpc/rtl/units/x86_64-linux -Cg -dx86_64 -dRELEASE -XX -CX -viq gdbint/src/gdbver.pp failed with exit code 256. Console output: Target OS: Linux for x86-64 Compiling gdbint/src/gdbver.pp Linking gdbint/bin/x86_64-linux/gdbver gdbver.pp(104,1) Error: Error while linking gdbver.pp(104,1) Fatal: There were 1 errors compiling module, stopping Fatal: Compilation aborted /usr/bin/ld: warning: gdbint/bin/x86_64-linux/link.res contains output sections; did you forget -T? /usr/bin/ld: cannot find libgdb.a ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
