Re: [fpc-devel] String and UnicodeString and UTF8String
On 01/10/2011 04:27 PM, Marco van de Voort wrote: And what do we do if e.g. Lazarus changes opinion and goes from utf8 to utf16 on Windows? (e.g. the Delphi/unicode becomes the dominant influx). The current way Lazarus works (UTF-8 in a String Type called "ANSIString", as well with Windows as with Linux without any auto-Conversion, introducing funny problems e.g. when just assigning a string constant to a Widestring) does not seem very appropriate. I feel the logical move would be to use the dynamically encoded string type in the LCL API, but there might be some nasty hidden problems (e.g. with var parameters). -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] String and UnicodeString and UTF8String
On 01/10/2011 04:27 PM, Marco van de Voort wrote: I think in the planned Embarcadero cross-compile products, string will also be utf-16 on OS X and Linux. Yak, I had hoped that using the dynamically encoded string type nearly everywhere would allow for a great lot of not OS-specific code in the VCL (and LCL) without the need for excessive conversions maintaining the systems' coding (UTF-16 or UTF-8) in and out with GUI-centric user code. I thought this would have been the main reason for introducing the additional complexity of the dynamically encoded string type. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] String and UnicodeString and UTF8String
I think at most two are required for any target: unicodestring (D2009 compatibility), and if really necessary because somehow the unicodestring version causes too much overhead, an ansistring($) version as well. That's only for the classes though, I think most of the base RTL can be simply ansistring($). So if I understand correctly, then UnicodeString and also AnsiString types must "be extended" that they will hold also information about actual codepage (encoding) of string data they hold. (AFAIK ATM they hold only information about "reference count" and "size" and of course "data") I am not expert, so I do not understand all aspect/problems which are joined with proper string handling, but some kind of implicit conversions (based on actual encoding of string data) is necessary (ANSI <-> UTF-8 <-> UTF-16 <-> ANSI ... etc.). For example known problem with Euro currency symbol. In Windows is in CurrencyString global variable stored using ANSI codepage, but used in LCL (which expect UTF-8 encoding) without any explicit conversion, what leads to displayng "?" instead of "€" (for example in TDBEdit or TDBGrid) Another problem when displaying character data in data-aware database controls (TDBEdit, TDBGrid). Data-aware controls (LCL) reads data from TField descendatns (FCL) using TField.Text property which returns "string" (without codepage information is not clear if it is AnsiString or UTF8String or UnicodeString). LCL expect UTF-8 strings, but it is not true in all cases (for example in case of ODBC) -Laco. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: dwarf3 and others too [Re: [fpc-devel] Dwarf3 and the encoding of classes]
On Tue, 2011-01-11 at 00:23 +, Martin wrote: > I did some more test., I will check in later... > > None of the old dwarf or stabs seems to define the <> operator for classes. > p Foo<>Bar > gives unknown symbold Foo<>Bar > So it does take it as one symbol? > > > nil > nil is not defined ever. > but under stabs dwarf2 Foo=0 works > > > Dwarf 3: > While the debugger can not do "@ArgTFoo^" in any stabs/dwarf, with the > older formats it can do "(@ArgTFoo)^" (apparently a question of the > order in which the operators are applied) > Under dwarf 3 this fails. > It outputs a class, so it has correctly gotten the type => but the data > in the class, the values of the members are wrong. So it may have > somewhere messed the address up ? > > > a: PAnsiString = 'abc' > -data-evaluate-expression a^ > empty string, but shopuld be 'abc' Martin, you go way too fast. ;) The decision to change the Dwarf3-object behavior was taken yesterday, and not even final. So now a patch has to be written and committed. (Well, it is written...) Same for variants and the enumerations. Your input is valuable, though. Maybe better to open bug-reports for the variants and enumerations. So it won't be forgotten. For now I my main point is to get a proper case-sensitivity fix. Without that the rest of dwarf-3 is useless anyway. btw: you can see what is changed for Dwarf-3 yourself very easily. It's all in compiler/dbgdwarf.pp. The Dwarf-3 class overrides some methods. (Indeed also those for variants) Joost. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] String and UnicodeString and UTF8Stringt
In our previous episode, Michael Schnell said: > I had hoped that using the dynamically encoded string type nearly > everywhere would allow for a great lot of not OS-specific code in the > VCL (and LCL) without the need for excessive conversions maintaining the > systems' coding (UTF-16 or UTF-8) in and out with GUI-centric user code. That was our original idea. But it also required the input granularity (1,2 maybe 4) to be a variable. > I thought this would have been the main reason for introducing the > additional complexity of the dynamically encoded string type. Embacadero however decided otherwise and kept a wall between the 1 and 2 byte types. So at least 1 and 2 byte types as basetype are different targets. I still have to study Jonas last message. It seems to indicate that I misunderstood what rawbytestring. If that is true, Jonas is right, separating the targets will result in two targets (rawbytestring and unicodestring) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Dwarf3 and the encoding of classes
On Mon, 2011-01-10 at 20:43 +, Martin wrote: > On 10/01/2011 20:26, Joost van der Sluis wrote: > > On Mon, 2011-01-10 at 01:12 +, Martin wrote: > >> On 03/01/2011 11:30, Joost van der Sluis wrote: > >>> I also promised to build a Windows-gdb binary with the latest Dwarf-3 > >>> patches from the Archer-project. This can be downloaded here: > >>> > >>> http://www.lazarussupport.com/downloads/gdb_win32_fedora15_with_pascal_patches.zip > >>> > >> That one just crashed, when I tested with stabs > > Works here. Do you have an example program? > > The latest version of my testcase. There's a new version at that location now. This one has a better case-sensitivity patch and support for viewing class-constants. For those interested... Joost. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Dwarf3 and the encoding of classes
11.01.2011 16:54, Joost van der Sluis wrote: http://www.lazarussupport.com/downloads/gdb_win32_fedora15_with_pascal_patches.zip That one just crashed, when I tested with stabs Works here. Do you have an example program? The latest version of my testcase. There's a new version at that location now. This one has a better case-sensitivity patch and support for viewing class-constants. For those interested... Forbidden You don't have permission to access /downloads/gdb_win32_fedora15_with_pascal_patches.zip on this server. Best regards, Paul Ishenin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] String and UnicodeString and UTF8Stringt
On 11 Jan 2011, at 10:47, Marco van de Voort wrote: I still have to study Jonas last message. It seems to indicate that I misunderstood what rawbytestring. If that is true, Jonas is right, separating the targets will result in two targets (rawbytestring and unicodestring) Here's some nice explanation about how rawbytestring behaves in practice: http://www.micro-isv.asia/2008/08/using-rawbytestring-effectively/ And here's an answer by Barry Kelly to a post about rawbytestring explaining what the purpose of the type is (similar to what I said): http://www.codegod.de/WebAppCodeGod/Delphi-2009-RawByteString-vagaries-QID85470.aspx He mentions using them as parameter types to reduce the number of overloads, but I'm still wondering about var-parameters in particular. I would guess that it may very well be forbidden to pass an ansistring(0) to a rawbytestring var-parameter, so it would still not solve everything in that case (and if it's not forbidden, I'm curious how you can obtain the statically defined codepage of the ansistring(0) at the callee side in case the input string was empty). Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] String and UnicodeString and UTF8Stringt
On 01/11/2011 10:47 AM, Marco van de Voort wrote: But it also required the input granularity (1,2 maybe 4) to be a variable. Sorry I don't understand what you mean with this. Embacadero however decided otherwise and kept a wall between the 1 and 2 byte types. So at least 1 and 2 byte types as basetype are different targets. Unfortunately I don't have Delphi > 2007. From what O read I understand that the dynamically code string type can hold 1, 2, and 4 byte (maybe even more) Codes for it's elements (denoted in one control-value) and each of those (theoretically) in different coding schemes (denoted in another control-value), allowing e.g. for UTF-8, UTF-16, UCS4, German ANSI, raw Byte, string Each assignment would auto recode the string "if necessary". I suppose that s1 := s2 would not do any recoding, but s1 := s2 + s3; would automatically synchronize the coding. I suppose there are ways do define the coding (and force recoding), maybe similar to "setlength(s, 10)". -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] String and UnicodeString and UTF8Stringt
On 01/11/2011 11:11 AM, Jonas Maebe wrote: in case the input string was empty). As the coding scheme and element size are control-block-variables it seems that even an empty string should have the appropriate definitions. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Dwarf3 and the encoding of classes
On Tue, 2011-01-11 at 17:02 +0700, Paul Ishenin wrote: > 11.01.2011 16:54, Joost van der Sluis wrote: > > http://www.lazarussupport.com/downloads/gdb_win32_fedora15_with_pascal_patches.zip > > > That one just crashed, when I tested with stabs > >>> Works here. Do you have an example program? > >> > >> The latest version of my testcase. > > > > There's a new version at that location now. This one has a better > > case-sensitivity patch and support for viewing class-constants. For > > those interested... > > Forbidden > > You don't have permission to access > /downloads/gdb_win32_fedora15_with_pascal_patches.zip on this server. Fixed. Joost ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] String and UnicodeString and UTF8Stringt
In our previous episode, Michael Schnell said: > Sorry I don't understand what you mean with this. > > Embacadero however decided otherwise and kept a wall between the 1 and 2 > > byte types. So at least 1 and 2 byte types as basetype are different > > targets. > Unfortunately I don't have Delphi > 2007. From what O read I understand > that the dynamically code string type can hold 1, 2, and 4 byte (maybe > even more) Codes for it's elements (denoted in one control-value) and > each of those (theoretically) in different coding schemes (denoted in > another control-value), allowing e.g. for UTF-8, UTF-16, UCS4, German > ANSI, raw Byte, string That is wrong. Better read up on that. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] String and UnicodeString and UTF8Stringt
On 01/11/2011 02:05 PM, Marco van de Voort wrote: That is wrong. Better read up on that. AFAIK, this is what they announced some time ago, Seemingly it turned out to be done some other way... Nonetheless fpc seems to intend to offer something like this (right now in an experimental branch). -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] String and UnicodeString and UTF8Stringt
On 11 Jan 2011, at 10:47, Marco van de Voort wrote: Embacadero however decided otherwise and kept a wall between the 1 and 2 byte types. So at least 1 and 2 byte types as basetype are different targets. I'm actually not sure about that: the new ansistring type has a hidden "element size" field (in addition to the reference count, length and codepage), and from what I can see at page 10 of http://edn.embarcadero.com/article/images/38980/Delphi_and_Unicode.pdf , Delphi 2009's unicodestring is simply an ansistring(1200). Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Dwarf3 and the encoding of classes
On 11/01/2011 09:54, Joost van der Sluis wrote: There's a new version at that location now. This one has a better case-sensitivity patch and support for viewing class-constants. For those interested... The new one crashes, when my test application is run (dwarf and dwarf 3): >> TCmdLineDebugger.SendCmdLn "-exec-continue" << TCmdLineDebugger.ReadLn "^running" << TCmdLineDebugger.ReadLn "*running,thread-id="all"" << TCmdLineDebugger.ReadLn "(gdb) " << TCmdLineDebugger.ReadLn "&"stack.c:293: internal-error: print_frame_args: Assertion `nsym != NULL' failed.\nA probl m internal to GDB has been detected,\nfurther debugging may prove unreliable."" [Debugger] Log output: &"stack.c:293: internal-error: print_frame_args: Assertion `nsym != NULL' failed.\nA problem in ernal to GDB has been detected,\nfurther debugging may prove unreliable." << TCmdLineDebugger.ReadLn "&"\n"" [Debugger] Log output: &"\n" << TCmdLineDebugger.ReadLn "" << TCmdLineDebugger.ReadLn "This application has requested the Runtime to terminate it in an unusual way. lease contact the application's support team for more information." [DBGTGT] This application has requested the Runtime to terminate it in an unusual way. lease contact the application's support team for more information. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Dwarf3 and the encoding of classes
On Tue, 2011-01-11 at 15:59 +, Martin wrote:
> On 11/01/2011 09:54, Joost van der Sluis wrote:
> >
> > There's a new version at that location now. This one has a better
> > case-sensitivity patch and support for viewing class-constants. For
> > those interested...
> >
> The new one crashes, when my test application is run (dwarf and dwarf 3):
I coudn't reproduce, but I had some local changes. I reverted them and
now I also have some strange results. I have no time to invest this now
any further. But maybe you can try with my local changes. (Although in
principle this shoudn't make any difference)
Index: gdbmidebugger.pp
===
--- gdbmidebugger.pp(revision 28962)
+++ gdbmidebugger.pp(working copy)
@@ -2979,7 +2979,7 @@
// check whether we need class cast dereference
if ExecuteCommand('ptype TObject', R)
then begin
- if (LeftStr(R.Values, 15) = 'type = ^TOBJECT')
+ if (sametext(LeftStr(R.Values, 15),'type = ^TOBJECT'))
then include(TargetInfo^.TargetFlags, tfClassIsPointer);
end;
@@ -5437,6 +5437,7 @@
// for win32, turn off a new console otherwise breaking gdb will
fail
// ignore the error on other platforms
ExecuteCommand('-gdb-set new-console off', [cfIgnoreError]);
+ ExecuteCommand('-gdb-set case-sensitive off', []);
if not ParseGDBVersionMI then ParseGDBVersion;
CheckGDBVersion;
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Dwarf3 and the encoding of classes
On 11/01/2011 21:39, Joost van der Sluis wrote:
On Tue, 2011-01-11 at 15:59 +, Martin wrote:
On 11/01/2011 09:54, Joost van der Sluis wrote:
There's a new version at that location now. This one has a better
case-sensitivity patch and support for viewing class-constants. For
those interested...
The new one crashes, when my test application is run (dwarf and dwarf 3):
I coudn't reproduce, but I had some local changes. I reverted them and
now I also have some strange results. I have no time to invest this now
any further. But maybe you can try with my local changes. (Although in
principle this shoudn't make any difference)
+ ExecuteCommand('-gdb-set case-sensitive off', []);
IT could be this line => but with it, all my other gdb versions start
failing => including the one I use to run the testcase (the one I have
configured in lazarus / 7.2-1)
But it's the same line in the error msg => so seems there is something.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] String and UnicodeString and UTF8String
Marco van de Voort schrieb: Btw, while looking up rawbytestring I saw this in the Delphi help: "Declaring variables or fields of type RawByteString should rarely, if ever, be done, because this practice can lead to undefined behavior and potential data loss." IIRC RawByteString should be used like OpenString, as subroutine argument type only. In contrast to the name, a RawByteString has a variable encoding, i.e. implicit conversions are inserted for every use with other string types. Thus AnyByteString had been a better name for that type, IMO. Delphi does no more support (officially) non-textual data in strings, and TBytes should be used for such data. How will you deal with e.g. Windows? Legacy string=ansistring(0), D2009 is string=utf16 TUnicodestring? Is an Delphi UnicodeString really compatible with an WinAPI WideString/BSTR? AFAIR all BSTRs must reside in shared memory, so that copies are required for every API call. Mainly the question what the classtree will be. The main operating type used in applications. You always need two RTLs for that, since it can be 1 or 2 byte, and even if you fixated it on one byte encodings, rawbytestring would force you to write case statements in each and every procedure. UTF-8 combines an single (byte-based) storage type with lossless encoding of full Unicode. Ansi and UCS2 (really UTF-16) only *look* easier to handle in user code, but both will fail and require special code whenever characters outside the assumed codepage may occur. DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] String and UnicodeString and UTF8String
Jonas Maebe schrieb: This has the advantage that you always have all optimal implementations available, regardless of the platform or default string encoding. It does not require extra work because we have to write all those versions also if we want the RTL to be compilable for different default string encodings. And three checks in a case statement are not going to define the performance in a context of atomic reference counting, dynamic memory management and the occasional code page conversion (and since this may reduce the number of code page conversions when working with "non-native" strings, it can also be a performance win). IMO a single encoding, i.e. UTF-8, can cover all cases. While some hard core Ansi coders may whine about such a convention, the absence of implicit string conversions (except in external library calls) will make such applications more performant than mixed-encoding versions. The argument "my characters *always* will be inside my preferred codepage" will prove false sooner or later. While it's not up to a programming language to teach people the "better way of coding", the required efforts of the FPC/Lazarus developers IMO should have more weight. Why spend time in the design of multiple RTL/LCL versions, when a single version will be perfectly sufficient? DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] String and UnicodeString and UTF8String
Jonas Maebe schrieb: And we have to deal with Windows, where the default is UTF16. ... since Delphi 2009 uses (unicode)string everywhere, we need at least also unicode versions. Since the generic Delphi "string" type can be any Unicode encoding now, it IMO would be legal to use UTF-8 or UTF-32 for it internally, in FPC. Some code, expecting UCS2/BMP text only, may become a bit slower due to according conversions in indexed access to chars, but no other *implicit* conversions will ever occur. Likewise the generic "char" type could become a 32 bit type, so that it can hold *every* Unicode codepoint. For both "string" and "array of char" the "packed" keyword could be used to distinguish between different bytecount and encoding, where unpacked types contain UTF-32 chars. This would speed up user code with indexed access, in contrast to both UTF-8 and -16 encodings, and it would allow the user to optimize his code for either speed or size. Indexed access to packed types simply could be disallowed, without breaking anything since the default is "not packed". Just some more ideas... DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] String and UnicodeString and UTF8String
On 01/11/2011 11:10 AM, Hans-Peter Diettrich wrote: UTF-8 combines an single (byte-based) storage type with lossless encoding of full Unicode. Ansi and UCS2 (really UTF-16) only *look* easier to handle in user code, but both will fail and require special code whenever characters outside the assumed codepage may occur. Preface: I don't write international apps, and probably won't for the foreseeable future... Isn't all of this concentration on trying to make strings have single byte characters (who cares how they are encoded), using the argument that it is somehow faster, incorrect for just about any modern processor, including embedded CPU's such as ARM? It was my understanding that 32 bit aligned access was always faster than byte aligned access on just about any CPU FPC still supports. The argument holds just fine for memory, but I don't really get the speed argument. Maybe I'm missing something. Jeff. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Proposal: Supporting initial references for weakexternal
While trying to find a nice solution for generating interrupt vector tables on ARM, I found that the usually employed solution is to generate weak references to symbols, that are initialized to a single handler. This way an application can override the weak reference, by declaring a new symbol with the same name. While it's possible to do that currently by using some external assembler code, I think a simpler solution could be made by using the weakexternal directive. The infrastructure is already there, but it's used in a slightly different way. An added bonus of using this new way is that IRQs will branch directly to the handler, instead of first branching to some code that loads the handler address, and then branching to the handler I've modified the syntax for this directive slightly, so it can take the form "weakexternal ['library'] [name 'name'] [set 'initialvalue'];" instead of "weakexternal ['library'] [name 'name'];" A short example: procedure NoHandler; begin end; procedure TestProc; weakexternal name 'TestProc' set 'NoHandler'; ... begin TestProc; // This will call NoHandler end. If we modify the example: procedure NoHandler; begin end; procedure TestProcHandler; [public, alias: 'TestProc']; begin end; procedure TestProc; weakexternal name 'TestProc' set 'NoHandler'; ... begin TestProc; // This will call TestProcHandler end. All this is done either at compile time, or link time What do you think about this proposal? I've put a patch up here: http://j-software.dk/new/weakexternal.txt And a small example of how lpc21x4.pp, for example, could be modified to use the new functionality: http://j-software.dk/new/lpc21x4.txt ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Proposal: Supporting initial references for weakexternal
12.01.2011 12:29, Jeppe Johansen wrote: A short example: procedure NoHandler; begin end; procedure TestProc; weakexternal name 'TestProc' set 'NoHandler'; ... begin TestProc; // This will call NoHandler end. If we modify the example: procedure NoHandler; begin end; procedure TestProcHandler; [public, alias: 'TestProc']; begin end; procedure TestProc; weakexternal name 'TestProc' set 'NoHandler'; ... begin TestProc; // This will call TestProcHandler end. As I understand NoHandler will be called if we call a TestProc routine but 'TestProc' symbol is is not found? If so then: a) NoHandler must have the same arguments and calling convention as TestProc? b) What happen if NoHandler is not found? Best regards, Paul Ishenin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] [fpprofiler] bug
http://bugs.freepascal.org/view.php?id=18471 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] String and UnicodeString and UTF8Stringt
...: the new ansistring type has a hidden "element size" field (in addition to the reference count, length and codepage), and from what I can see at page 10 of http://edn.embarcadero.com/article/images/38980/Delphi_and_Unicode.pdf, Delphi 2009's unicodestring is simply an ansistring(1200). So it seems, that if we will have any "GenericString", with properties "reference count", "size", "character width", "codepage", then all other string types can be based on this string type. So other strings will be only any "shortcuts", and internaly will use same structure: AnsiString = GenericString(with actual system ANSI code page (0) ... or ... without any explicit codepage ($)) UTF8String = GenericString(with UTF-8 encoding) UnicodeString = GenericString(with UTF-16 encoding) So it seems to me, that there is agreement on adding "character width", "codepage" to internal "string" record structure and provide conversions where needed, isn't it ? (more or less same approach like in Delphi) Where is not agreement, it is fact what should be default string encoding (AnsiString($) or UTF-8 or UTF-16 or UTF-32) So if I revert to my original question ... is there any agreement on some points related to "future of String type" ? P.S. I still does not understand, how can things work correctly if LCL expect that all AnsiStrings (String) are UTF8Strings, byt RTL/FCL does not strictly follow this (at least in Windows) ? -Laco. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Proposal: Supporting initial references for weakexternal
Den 12-01-2011 06:56, Paul Ishenin skrev: 12.01.2011 12:29, Jeppe Johansen wrote: A short example: procedure NoHandler; begin end; procedure TestProc; weakexternal name 'TestProc' set 'NoHandler'; ... begin TestProc; // This will call NoHandler end. If we modify the example: procedure NoHandler; begin end; procedure TestProcHandler; [public, alias: 'TestProc']; begin end; procedure TestProc; weakexternal name 'TestProc' set 'NoHandler'; ... begin TestProc; // This will call TestProcHandler end. As I understand NoHandler will be called if we call a TestProc routine but 'TestProc' symbol is is not found? If so then: a) NoHandler must have the same arguments and calling convention as TestProc? With this solution, no. This uses only symbol names b) What happen if NoHandler is not found? Then TestProc cannot be resolved to any symbol, and will generate a weak undefined reference. Eg. it won't complain about an undefined reference ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Proposal: Supporting initial references for weakexternal
12.01.2011 13:21, Jeppe Johansen wrote: a) NoHandler must have the same arguments and calling convention as TestProc? With this solution, no. This uses only symbol names This I don't understand. What happen when I call DoSomething(1, 'test'); But DoSomething is not resolved and instead HandleDoSomethingUnresolved() is called? Is there a chance to access my arguments from that handler or no? What happen if I pass some argument by reference and expect a result or do a function call: Value := CallSomething(); // What Value equal to if CallSomething is not resolved? b) What happen if NoHandler is not found? Then TestProc cannot be resolved to any symbol, and will generate a weak undefined reference. Eg. it won't complain about an undefined reference I don't see where you reference the "weakinitial" symbol in your patch that's why I'm asking this question. If NoHandler is not referenced it will be stripped away during the linking process? Generally I want to have an ability to handle a case where I call an unresolved symbol but I want to be sure that I receive arguments and my handler will not be striped from the executable. I'd better suggest the next syntax: procedure NoHandler; begin end; procedure TestProc; weakexternal name 'TestProc' set NoHandler; In this case I'm sure that: 1. NoHandler is a valid identifier which points to a procedure. 2. I can check that NoHandler has compatible with TestProc definition. 3. I can reference NoHandler so it will not be removed away from the executable. Although I may be just don't understand your proposal. Best regards, Paul Ishenin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Proposal: IIF - IfThen Cond True False
12.01.2011 13:28, kingbiz...@gmail.com wrote: The problem: we have to do *one function for every type*, on the C and PHP method is is *globally* If we want one for Integer we must declare one for it, if we want one for X we need to declare it... I want to know from you, what you would think about it on FPC? I don't belive that it is a hard feature to implement and is helpfull. I'll be waiting for your response! Similar to delphi generic method: function IIf(Condition: Boolean; IfTrue, IfFalse: T): T; begin if Condition then Result := IfTrue else Result := IfFalse; end; I'm working on this functionality for classes, objects and record methods. But even delphi does not have it for regular procedures/functions. I suppose because regular procedures/functions does not support overloading. Best regards, Paul Ishenin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] String and UnicodeString and UTF8String
In our previous episode, Jeff Wormsley said: > > encoding of full Unicode. Ansi and UCS2 (really UTF-16) only *look* > > easier to handle in user code, but both will fail and require special > > code whenever characters outside the assumed codepage may occur. > > Preface: I don't write international apps, and probably won't for the > foreseeable future... > > Isn't all of this concentration on trying to make strings have single > byte characters (who cares how they are encoded), using the argument > that it is somehow faster, incorrect for just about any modern > processor, including embedded CPU's such as ARM? > It was my > understanding that 32 bit aligned access was always faster than byte > aligned access on just about any CPU FPC still supports. 1-byte access is always 1-byte aligned, and the memory system is still slower than these kind of issues. And you shuffle a lot of zeroes extra around. But the trouble is also that 2-byte situation doesn't really solve anything, (you still have surrogates and it never will be as simple as it was), and a much bigger problem with legacy (how many two byte data do you get daily, and how much 1 byte?) > The argument holds just fine for memory, but I don't really get the > speed argument. Maybe I'm missing something. Shoveling twice as much memory around IS the speed argument :-) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Proposal: IIF - IfThen Cond True False
In our previous episode, Paul Ishenin said: > But even delphi does not have it for regular procedures/functions. I > suppose because regular procedures/functions does not support overloading. ??? I use it all the time? Requires overload directive iirc, but works. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Proposal: IIF - IfThen Cond True False
12.01.2011 13:47, Marco van de Voort пишет: In our previous episode, Paul Ishenin said: But even delphi does not have it for regular procedures/functions. I suppose because regular procedures/functions does not support overloading. ??? I use it all the time? Requires overload directive iirc, but works. Indeed... I somehow have misled myself. Well, then I don't know the reason why delphi does not have generic functions/procedures. Best regards, Paul Ishenin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Proposal: IIF - IfThen Cond True False
Em 12/01/2011 04:47, Marco van de Voort escreveu: In our previous episode, Paul Ishenin said: But even delphi does not have it for regular procedures/functions. I suppose because regular procedures/functions does not support overloading. ??? I use it all the time? Requires overload directive iirc, but works. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel Well guys, thanks for replying, the generic method is a very nice method, I personally didn't know that the FPC support it, very thank you for that! ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Proposal: IIF - IfThen Cond True False
12.01.2011 13:54, kingbiz...@gmail.com пишет: Well guys, thanks for replying, the generic method is a very nice method, I personally didn't know that the FPC support it, very thank you for that! FPC does not support it at the moment. I hope it will in a month. Best regards, Paul Ishenin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Proposal: IIF - IfThen Cond True False
Em 12/01/2011 05:00, Paul Ishenin escreveu: 12.01.2011 13:54, kingbiz...@gmail.com пишет: Well guys, thanks for replying, the generic method is a very nice method, I personally didn't know that the FPC support it, very thank you for that! FPC does not support it at the moment. I hope it will in a month. Best regards, Paul Ishenin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel Ok, I'll be waiting for that! Guys, you reply fast and nice! Thank you again, anyways =) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Variables declaraction inside code
Something that I always thought very nice on other languages is the possible of adding variables inside the codes, I'm very happy using the FPC but came on my mind, FPC is always getting better and better (I first saw it like 2 years ago and I am impressed with its progress), would it on the future be possible? Declaring variables after the begin? /*Just random thoughts*/ Thank you, Bizz ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Proposal: Supporting initial references for weakexternal
b) What happen if NoHandler is not found?
Then TestProc cannot be resolved to any symbol, and will generate a weak
undefined reference. Eg. it won't complain about an undefined reference
I don't see where you reference the "weakinitial" symbol in your patch
that's why I'm asking this question. If NoHandler is not referenced it
will be stripped away during the linking process?
Generally I want to have an ability to handle a case where I call an
unresolved symbol but I want to be sure that I receive arguments and
my handler will not be striped from the executable.
I'd better suggest the next syntax:
procedure NoHandler;
begin
end;
procedure TestProc; weakexternal name 'TestProc' set NoHandler;
In this case I'm sure that:
1. NoHandler is a valid identifier which points to a procedure.
2. I can check that NoHandler has compatible with TestProc definition.
3. I can reference NoHandler so it will not be removed away from the
executable.
Although I may be just don't understand your proposal.
Best regards,
Paul Ishenin
Very good idea. It would make alot of sense to do that
Regarding referencing to prevent removal:
weakinitial is referenced through the .set directive here
AsmWriteLn('.set'#9+tasmsymbol(current_asmdata.AsmSymbolDict[i]).Name+','+tasmsymbol(current_asmdata.AsmSymbolDict[i]).weakinitial.Name)
This explicitly tells the linker that either the label TestProc has the
value weakinitial.name; or if the label TestProc is defined somewhere
else take on that value. IfTestProc exists then there would be no need
for NoHandler, so it would be fine if it was stripped from the
executable. If neither isn't there we would have a problem of course,
which your idea would solve
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
