Re: [fpc-devel] Explanation about code page-aware AnsiStrings

Jonas Maebe schrieb: http://wiki.freepascal.org/FPC_Unicode_support (only Sections 1 to 3; 4 and later are older and mostly either incomplete or wishful thinking). Just a note on RawByteString concatenation: Delphi concatenates RawByteStrings to the dynamic encoding of the *first* string, th

Re: [fpc-devel] Encoded AnsiString

Jonas Maebe schrieb: On 07 Jan 2014, at 15:35, Hans-Peter Diettrich wrote: 2) The stupid conversion to CP_ACP in an assignment *to* an RawByteString should be dropped. This applies in detail to the assignment to *function results*. The conversion does not happen for all assignments, it only

Re: [fpc-devel] Explanation about code page-aware AnsiStrings

Jonas Maebe schrieb: Large parts of the returning discussions about code page-aware AnsiStrings are related to the fact that many people don't how they work. For this reason I've created an overview that explains the rules that are followed by the RTL/compiler at http://wiki.freepascal.org/FP

Re: [fpc-devel] Encoded AnsiString

Jy V schrieb: A quick note: the new LLVM Delphi compiler forbid the use of AnsiString and AnsiChar, (declared in the unit AnsiString.pas, you cannot use this unit anyway), The compiler supports AnsiStrings, but these are hidden for *mobile* targets. There exists a hack to enable AnsiString s

Re: [fpc-devel] Encoded AnsiString

Michael Van Canneyt schrieb: If you want a TStrings that can hold strings which may differ in their encoding (i.e. strings[0] has a different encoding from strings[1]) then you'll be left in the cold. Just an idea: What if FPC adds another encoding, similar to RawByteString ($), but with

Re: [fpc-devel] Encoded AnsiString

Paul Ishenin schrieb: 30.12.2013 9:07, Hans-Peter Diettrich пишет: Do you think that FPC should really reproduce all this inconsistent behaviour? Who would test or even specify the compatible behaviour, when every new variation will result in more unexpected results? IMO it's much easi

Re: [fpc-devel] Encoded AnsiString

Jonas Maebe schrieb: I'm inclined to add a global boolean variable to the system unit that allows changing this behaviour so that it uses CP_UTF8 instead in such cases (defaulting to false, for Delphi compatibility). In practice, setting it to true shouldn't cause problems even with virtually al

Re: [fpc-devel] Encoded AnsiString

Sven Barth schrieb: [...] This was tested using Delphi XE (it might not compile though as I've just rewritten the code from memory as the original is on a different computer) Thanks, the code is okay, and it produces the expected results. The compiler also warns about a downcast from 'string

Re: [fpc-devel] Encoded AnsiString

Jonas Maebe schrieb: The code page of ansistrings concatenations is the code page of the result to which this concatenation is assigned/converted. For rawbytestring, this code page is CP_ACP per Delphi compatibility. This does not match my experience with Delphi XE :-( Can you give an Delphi

Re: [fpc-devel] Encoded AnsiString

Michael Van Canneyt schrieb: On Sun, 29 Dec 2013, Hans-Peter Diettrich wrote: This will be combined with the dotted unit filenames, to be Delphi 2010+ compatible. How do I create source files for use with both versions? What do you mean by this statement ? I'm not familiar

Re: [fpc-devel] Encoded AnsiString

Michael Van Canneyt schrieb: On Sun, 29 Dec 2013, Hans-Peter Diettrich wrote: Inspired by the current Lazarus discussion I'd like to learn more about the current state of the implementation of the new AnsiStrings. In case nothing has be done yet, I'd suggest to extend TAnsiRec b

[fpc-devel] Encoded AnsiString

Inspired by the current Lazarus discussion I'd like to learn more about the current state of the implementation of the new AnsiStrings. In case nothing has be done yet, I'd suggest to extend TAnsiRec by the new codePage and elemSize fields (words). These can be zero for now, so that the remain

Re: [fpc-devel] Multithreading under DOS

Tomas Hajny schrieb: My first notebook had 4 MB RAM, and Win3.1 and Word 1.0 worked very well on it :-) Yes, but windows 3.1 is a DOS extender :) Yes. Moreover, an extender not featuring multi-threading and even the multitasking wasn't preemptive if I remember correctly. I remember running

Re: [fpc-devel] Multithreading under DOS

Nikolay Nikolov schrieb: On 09/26/2013 09:41 PM, Hans-Peter Diettrich wrote: Nikolay Nikolov schrieb: On 09/26/2013 08:24 PM, Leif Ekblad wrote: DOS extenders are even worse candidates for multitasking than DOS. And if you aim to use 32-bit anyway, I see no reason to use an DOS extender over

Re: [fpc-devel] Multithreading under DOS

Nikolay Nikolov schrieb: On 09/26/2013 08:24 PM, Leif Ekblad wrote: DOS extenders are even worse candidates for multitasking than DOS. And if you aim to use 32-bit anyway, I see no reason to use an DOS extender over a real multitasking OS. Low resource usage perhaps. How well does Linux run on

Re: [fpc-devel] Multithreading under DOS

Sven Barth schrieb: Well, we do have a TThread.Yield procedure since the last time I worked on TThread :) What does it do on a DOS target? DoDo ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/f

Re: [fpc-devel] Multithreading under DOS

Michael Schnell schrieb: On 09/26/2013 01:28 PM, Tomas Hajny wrote: suggests that pre-emptive multithreading is hardly possible (if at all) with pure user space implementation; FPC TThread design is based on an assumption of a pre-emptive multithreading. In fat, already many years ago, I did

Re: [fpc-devel] cpstrrtl/unicode branch merged to trunk

Sven Barth schrieb: > Sorry, I didn't look at or step through the generated code. I still > doubt that a concatenation function gets an TargetEncoding argument. The target string is passed as var-parameter and thus the codepage can be queried using StringCodePage. See fpc_ansistr_concat in

Re: [fpc-devel] cpstrrtl/unicode branch merged to trunk

Hans-Peter Diettrich schrieb: I think that a "can't decide which overloaded function to call" error would be just as logical. You are right, all calls are ambiguous except test(b). Correction: only test(a) is accepted. DoDi ___ fpc

Re: [fpc-devel] cpstrrtl/unicode branch merged to trunk

Jonas Maebe schrieb: On 07 Sep 2013, at 01:39, Hans-Peter Diettrich wrote: Jonas Maebe schrieb: On 06 Sep 2013, at 13:54, Hans-Peter Diettrich wrote: That conversion IMO is done by the every concatenation, apart from subroutine considerations. I think you mean "afaik" rather than

Re: [fpc-devel] cpstrrtl/unicode branch merged to trunk

Jonas Maebe schrieb: On 06 Sep 2013, at 13:54, Hans-Peter Diettrich wrote: Jonas Maebe schrieb: o merged cpstrrtl branch (includes unicode branch). In general, this adds support for arbitrarily encoded ansistrings to many routines related to file system access (and some others). WARNING

Re: [fpc-devel] cpstrrtl/unicode branch merged to trunk

Sven Barth schrieb: Am 06.09.2013 14:16 schrieb "Hans-Peter Diettrich" <mailto:drdiettri...@aol.com>>: > I'm not sure how efficient a RawByteString version ever can be. By default it has to convert the string into Unicode (Delphi: UTF-16), and the result back to CP_A

Re: [fpc-devel] cpstrrtl/unicode branch merged to trunk

Michael Schnell schrieb: Of course I need to jump in here ... Of course ;-) While I don't exactly know what you are up to, you might want to read some recent posts of mine where I pointed out that using a fully dynamically encoding auto-converting String type (which does not seem to exist

Re: [fpc-devel] cpstrrtl/unicode branch merged to trunk

Jonas Maebe schrieb: Hi, I've just merged the cpstrrtl/unicode branch into trunk. Below you can find the commit message, which describes most changes, the added features and also a very important warning. Jonas o merged cpstrrtl branch (includes unicode branch). In general, this adds

Re: [fpc-devel] Re. z370 Cross Compilation, Pass 2 of ....

Mark Morgan Lloyd schrieb: Hans-Peter Diettrich wrote: Mark Morgan Lloyd schrieb: Question (to save me digging into the manuals right now): where a recent machine uses the dedicated stack instructions, is the stack pointer one of the standard registers? In other words, can push/pop

Re: [fpc-devel] Re. z370 Cross Compilation, Pass 2 of ....

Mark Morgan Lloyd schrieb: So at the very least, we have to consistently simulate a stack- apart from anything else, that's mandated by Pascal's use of recursion. But we don't necessarily have to use the same calling convention for Linux and for "classic" OSes (i.e. including those which are f

Re: [fpc-devel] Re. z370 Cross Compilation, Pass 2 of ....

Bernd Oppolzer schrieb: Am 20.08.2013 16:54, schrieb Mark Morgan Lloyd: > Just to name a few: you'll need to get parameter passing for functions > correctly Which leads to another issue: the 370 is a register-based system without a stack as understood today. Parameters are mostly passed in re

Re: [fpc-devel] Re. z370 Cross Compilation, Pass 2 of ....

Steve schrieb: > > If we use gas/ld we put ourselves in the same situation Delphi landed > > us in with the use of non-standard libraries; Writing individual > > wrapper functions for every other function under the sun. > Would you elaborate what you mean here? Sorry, isn't this a universa

Re: [fpc-devel] Re: Porting FPC to IBM zArch

Mark Morgan Lloyd schrieb: Apropos Paul's comments of doing a good cross-reference and handling compiler directives, I think the thing that is likely to give real problems is the {$if defined() } form... I'm not sure whether $if defined() works with ordinary constants. The $DEFINE and CONST

Re: [fpc-devel] TCustomApplication

Michael Schnell schrieb: So - if I would start doing anything on that behalf - I would do something with as wide reach as possible: providing (at least) all of TTimer, TThread.Synchronize, TThread,Queue, and Application.QueuAsnycCall, as well for Linux and for Windows in a "ready to use" way

Re: [fpc-devel] RawString

Michael Schnell schrieb: 5) In DXE the TStringList (and supposedly TStrings) class uses "String" as it's user interface, In Delphi, "String" is mapped to a Type that is strictly encoded as a (windowish) two-Byte Unicode Type. This results in a huge performance hit when using it with a (normal

Re: [fpc-devel] Performance of string handling in trunk

Michael Schnell schrieb: 2) Nothing is copied on an assignment to a string variable, except the reference to the memory object. Sorry, I erroneously thought about the variable itself being ref counted, while in fact the variable is a pointer to the (hidden) String management record, Fine

Re: [fpc-devel] Performance of string handling in trunk

Sven Barth schrieb: > IMO a reasonable decision should take into account the use of the RawByteString type in RTL code, e.g. for concatenation. The RTL already uses RawByteString for the concatenation helpers. This means that the assumptions implied by that code have to be matched by the R

Re: [fpc-devel] Performance of string handling in trunk

Michael Schnell schrieb: On 06/26/2013 02:59 PM, Sven Barth wrote: ... And using SetCodePage you can force a conversion. The docs say: === procedure SetCodePage(var S: RawByteString; CodePage: Word; Convert: Boolean

Re: [fpc-devel] Performance of string handling in trunk

Michael Schnell schrieb: On 06/26/2013 03:44 PM, Marco van de Voort wrote: There never is a conversion when assigning to/from rawbytestring, So what do you suggest should happen when assigning a RawByteString to a normal String ? The result could be a strange thing that is encoded other th

Re: [fpc-devel] Performance of string handling in trunk

Michael Schnell schrieb: On 06/26/2013 12:05 PM, Hans-Peter Diettrich wrote: After an assignment both strings refer to the same memory, i.e. pchar(s1)=pchar(s2). Everything else indicates an error, somwehere. This is exactly what I wanted to show: it results in ContentPointer, StringLength

Re: [fpc-devel] Performance of string handling in trunk

Sven Barth schrieb: Am 26.06.2013 14:02, schrieb Michael Schnell: On 06/26/2013 01:40 PM, Sven Barth wrote: It's the whole use of RawByteString that the encoding is kept. For all other string types the content will be converted That is what I did assume, but I understood dodi in a way that he

Re: [fpc-devel] Performance of string handling in trunk

Michael Schnell schrieb: On 06/25/2013 01:20 PM, Hans-Peter Diettrich wrote: Michael Schnell schrieb: Supposedly the length and encoding number and code-bytecount is copied, too. Please understand reference counted memory objects :-] Please check this program I tested with a pre-Unicode

Re: [fpc-devel] Performance of string handling in trunk

Michael Schnell schrieb: On 06/24/2013 08:21 PM, Sven Barth wrote: AnsiString: up to 2^23-1 characters, reference counted, system encoding (determined by the code page at compilation time AFAIK) 8 or 16 bit codes ? In Delphi XE this seems to be 16 bit, in Delphi 7 and the currently relea

Re: [fpc-devel] Performance of string handling in trunk

Michael Schnell schrieb: On 06/25/2013 01:05 AM, Hans-Peter Diettrich wrote: A RawByteString can obtain any encoding, so no conversions are required. But when assigned back to an UnicodeString, the obtained encoding is used to convert the string. That sounds good. The name "RAW&

Re: [fpc-devel] Performance of string handling in trunk

Michael Schnell schrieb: On 06/25/2013 01:05 AM, Hans-Peter Diettrich wrote: In fact it looks like only the string pointers are copied between AnsiString and RawByteString, with the refcount changed accordingly. Supposedly the length and encoding number and code-bytecount is copied, too

Re: [fpc-devel] Performance of string handling in trunk

Sven Barth schrieb: On 24.06.2013 16:44, Hans-Peter Diettrich wrote: I hope, now I understand that the type RawByteString ( = String ($) ) means "codesize = 1 Byte, never to be auto-converted to any differently encoded String type variable. No. Even if I would like such an encoding

Re: [fpc-devel] Performance of string handling in trunk

Michael Schnell schrieb: On 06/24/2013 12:43 PM, Hans-Peter Diettrich wrote: I e.g. remember your strange (Delphi incompatible) opinions about RawByteString and encodings in a startup discussion. Yep. As I did not have DTX to try it, I only read what I could find in the internet and

Re: [fpc-devel] Performance of string handling in trunk

Michael Schnell schrieb: Could you give us a list of the different - legacy and to be supported - string types we might be seeing including their "official" names to make the discussion less ambiguous. This should be clear since a long time. I e.g. remember your strange (Delphi incompatible

Re: [fpc-devel] Performance of string handling in trunk

Michael Schnell schrieb: On 06/21/2013 02:20 PM, Hans-Peter Diettrich wrote: Please note that I was *not* talking about AnsiStrings. Sorry I don't understand. You snipped the context, which was UnicodeString (second case). The AnsiString case was covered before. I recon the OP a

Re: [fpc-devel] Performance of string handling in trunk

Michael Schnell schrieb: On 06/21/2013 09:54 AM, Hans-Peter Diettrich wrote: Again I'd assume that the memory allocation for the result is the most expensive operation with UnicodeString operands, independent from string lengths. Do you suggest that with UnicodeString - even when us

Re: [fpc-devel] Performance of string handling in trunk

Michael Schnell schrieb: On 06/20/2013 05:31 PM, luiz americo pereira camara wrote: The point is that i would expect a smaller performance hit when there's no conversion going on. Something between 10% slower. In the cited case is more than 50% slow. As the "dynamic" types of (most) String Var

Re: [fpc-devel] Closures via interfaces

Vasiliy Kevroletin schrieb: I described details of proposed and partly implemented approach in mantis. This is Delphi's approach. Some people call it "closures via interfaces". In slightly modified way it will allow to capture variables by value (which was requested in previous discussion). I

Re: [fpc-devel] Delphi language changes in iOS compiler

Michael Schnell schrieb: While all this seems to turn out as a major mess, I would like to see "$ZEROBASEDSTRINGS" in fpc, as well. In fact we should provide as many FPC/Lazarus versions *as* new Delphi versions introduce breaking changes. Some of the changes (from Ansi to Unicode, from VCL t

Re: [fpc-devel] Improper OUT usage.

Jonas Maebe schrieb: On 10 Mar 2013, at 22:08, Sven Barth wrote: On 10.03.2013 20:39, Flávio Etrusco wrote: I'd really like the compiler would stop with an error if it can't prove a variable/out/result is initialized. Did anybody try implementing this in FPC? Have fun fixing the errors then:

Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7

Henry Vermaak schrieb: I'm trying to ascertain if this is even possible (the c-style, file-at-a-time compilation, using make to handle multiple processes). Do you think it's possible, then? Yes and no. It would mean to create kind of header files for the Pascal units, usable to compile the un

Re: [fpc-devel] PPU version checking

Tomas Hajny schrieb: If you'd disable the check you would not be able to use e.g. a 2.4 unit with 2.6, because the PPU format is different and thus you'd definitely (not just perhaps!) get errors when the compiler reads the PPU file. In other words: _If_ someone is motivated enough for such a t

Re: [fpc-devel] for-in-index loop

Paul Ishenin schrieb: 29.01.13, 17:23, Hans-Peter Diettrich пишет: Paul Ishenin schrieb: At least it's more fun to implement something very new, instead of working on incomplete parts (loadable libraries, targets) which had been delayed due to problems. The same situation in Lazarus a

Re: [fpc-devel] for-in-index loop

Paul Ishenin schrieb: At least it's more fun to implement something very new, instead of working on incomplete parts (loadable libraries, targets) which had been delayed due to problems. The same situation in Lazarus and in many open source projects BTW. Where are your patches for loadable lib

Re: [fpc-devel] for-in-index loop

Paul Ishenin schrieb: 28.01.13, 21:20, Michael Van Canneyt wrote: Different people see different needs in language. There is nothing bad not to use and not understand some of the language features. tatata, you should always understand everything :) Very weak argument :) In your work you use

Re: [fpc-devel] RFC: Support for new type "tuple" v0.1

Alexander Klenin schrieb: Also note that in my version of proposal, nested tuples are impossible. I consider this an inacceptable restriction. Records can contain other records. Yes, but tuples are just a syntax for constructing/deconstructing records, not records themsleves. They can be conve

Re: [fpc-devel] RFC: Support for new type "tuple" v0.1

Sven Barth schrieb: The lack of element names results in bloated code and runtime overhead. See below. I don't see why it should result in bloated code and runtime overhead. ---> See below ;-) (a, b) := (b, a); // the compiler needs to ensure the correct usage of temps here! What wil

Re: [fpc-devel] RFC: Support for new type "tuple" v0.1

Preface: In the following I assume that tuples can be implemented by records. The proposed syntax extensions can be applied to records as well, they are not restricted to a new type. Alexander Klenin schrieb: On Sun, Jan 27, 2013 at 12:35 PM, Hans-Peter Diettrich wrote: (a, b) := (b, a

Re: [fpc-devel] RFC: Support for new type "tuple" v0.1

Sven Barth schrieb: * Description What are tuples? Tuples are an accumulation of values of different or same type where the order matters. Sounds familiar? They are in this regard similar to records, but it's only the order of an element that matters, not its name. So what does make them spe

Re: [fpc-devel] for-in-index loop

Alexander Klenin schrieb: I think you meant "array of const" instead of "open array", since open array is just a method to pass arbitrary-sized array (of a single element type, of course). Yes, indeed. I missed that you already mentioned "array of const" as a possible syntax/implementation.

Re: [fpc-devel] for-in-index loop

Alexander Klenin schrieb: 2) Indeed, introducing tuples to Pascal might be an alternative solution. Below is a proposal: 2.1) Tuple definition. Tuple is an anonymous list of values, possibly of different types. OPL: array of Variant. Also: Open Array. Where both are slow and clumsy to use, vio

Re: [fpc-devel] for-in-index loop

Michael Schnell schrieb: On 01/25/2013 10:52 AM, Mattias Gaertner wrote: The above UTF8 example misses some points My question was about the want for a construct that allows for accessing the n'th printable character in an UTF-8 string Everybody can write such a subroutine, when really ne

Re: [fpc-devel] Do bitwise operation (1 or 2) acre about the sign ? (Giving sign related hints on compilation)

Martin schrieb: During above calculation ("or") a sign extension is required because the result *must* have a definite sign. Else a following comparison of e.g. (x or j)>0 could not determine a result. This is casting a "set of bits" (neither signed, nor unsigned - a set is not a number at al

Re: [fpc-devel] Do bitwise operation (1 or 2) acre about the sign ? (Giving sign related hints on compilation)

Martin schrieb: On 14/01/2013 13:54, ik wrote: On Mon, Jan 14, 2013 at 3:11 PM, Martin wrote: Actually not so much about the hint, as about the fact that in the below example fpc extends the operands to 64 bits. program Project1; var x: cardinal; i, j: integer; begin i:= x or j end.

Re: [fpc-devel] utf8 in 2.6.0

Martin Schreiber schrieb: but I fear we can not use that information for development with Free Pascal because: " The string is represented internally as a Unicode string encoded as UTF-16. Characters in the Basic Multilingual Plane (BMP) take 2 bytes, and characters not in the BMP require 4 b

Re: [fpc-devel] String handling in trunk (was utf8 in 2.6.0)

Paul Ishenin schrieb: 05.01.13, 23:54, Michael Van Canneyt пишет: You are very much wrong. To start with, resource strings are not stored as Win32 resources. I personally think that resources should be stored in their native formats where is possible. This will allow to change them using so

Re: [fpc-devel] String handling in trunk (was utf8 in 2.6.0)

Michael Van Canneyt schrieb: IMO resource strings are for display purposes, so that UTF-8/16 encoding is expected by an OS API. AFAIR Win32 string resources are stored in UTF-16, You are very much wrong. Not really. I was talking about Win32 resources, not about what FPC makes from resour

Re: [fpc-devel] String handling in trunk (was utf8 in 2.6.0)

Michael Van Canneyt schrieb: On Sat, 5 Jan 2013, Jonas Maebe wrote: On 05 Jan 2013, at 12:53, Paul Ishenin wrote: ResourceStrings are stored as AnsiString type with 0 codepage (as I remember). Delphi now stores ResourceStrings as UnicodeString type. I think FPC will follow this in m_defau

Re: [fpc-devel] utf8 in 2.6.0

Martin Schreiber schrieb: but I fear we can not use that information for development with Free Pascal because: " The string is represented internally as a Unicode string encoded as UTF-16. Characters in the Basic Multilingual Plane (BMP) take 2 bytes, and characters not in the BMP require 4 b

Re: [fpc-devel] Where are parser sources?

Nicholas Ring schrieb: On 4/01/2013 7:10 AM, Andrzej Borucki wrote: 2013/1/3 Jonas Maebe > The parser is a manually written recursive-descent parser. There is no formal grammar. Thanks. It is possible restore EBNF grammar from this sources? It is d

Re: [fpc-devel] utf8 in 2.6.0

Jonas Maebe schrieb: And how works " {$codepage 8859-1} ... UnicodeStringVar:= 'abcd'#228#246#252#1092#1080#1089#1074; " ? That string contains codepoints > #255 and hence is a unicodestring rather than a single byte string. No conversion at either compile or run time happens, and the codepag

Re: [fpc-devel] Forwarded message about FPC statusy

Mark Morgan Lloyd schrieb: I've got machines which are older than that, but they've almost all got multiple processors. I can't remember the exact timing, but a Sun machine with 16x 80MHz chips would build the Linux kernel in a minute or so, so parallelisation at the make -j level can be a b

Re: [fpc-devel] Forwarded message about FPC status

Michael Van Canneyt schrieb: Well, let me just say that the idea of two RTL's is rather ridiculous too!! It's not different from Delphi, where the introduction of UnicodeString required a renewed RTL, VCL and IDE. Who should do the same for FPC and Lazarus, and tell the users that they eithe

Re: [fpc-devel] Forwarded message about FPC status

Leif Ekblad schrieb: IMO, I wouldn't support wide-character (UnicodeString) strings for anything new. In the beginning the wide-character string had the advantage of being able to represent all characters with 2 bytes, but this is no longer the case. I would switch to UTF-8 instead and keep ch

Re: [fpc-devel] Forwarded message about FPC status

Graeme Geldenhuys schrieb: Well, let me just say that the idea of two RTL's is rather ridiculous too!! It's not different from Delphi, where the introduction of UnicodeString required a renewed RTL, VCL and IDE. Who should do the same for FPC and Lazarus, and tell the users that they either

Re: [fpc-devel] Forwarded message about FPC status

Sven Barth schrieb: Am 17.12.2012 14:06, schrieb Hans-Peter Diettrich: Sven Barth schrieb: still no Delphi-like packages... They are planned long term, but they are no cheesecake feature. We need to implement them in a way so that at least the major platforms (Windows, Linux, Mac OS X) can

Re: [fpc-devel] Forwarded message about FPC status

Sven Barth schrieb: still no Delphi-like packages... They are planned long term, but they are no cheesecake feature. We need to implement them in a way so that at least the major platforms (Windows, Linux, Mac OS X) can make use of it and already the difference regarding procedure name resolu

Re: [fpc-devel] Please include gmp.dll in Win32 distribution of FPC 2.6.2 and later

Jonas Maebe schrieb: If a major problem is really the lack of standard support for arbitrary-precision arithmetic, does that not mean that C and C++ are no longer serious options either? IMO that leaves the domain of general purpose languages. Here I see the boundary at operator level. A lan

Re: [fpc-devel] Please include gmp.dll in Win32 distribution of FPC 2.6.2 and later

Nikolay Nikolov schrieb: As an ex-competitive programmer and multiple IOI and BOI medalist, let me try to explain, although I realize it might be difficult for "normal" programmers to understand, but let's just say that: - the people who setup the programming environment for these competition

Re: [fpc-devel] Please include gmp.dll in Win32 distribution of FPC 2.6.2 and later

Craig Peterson schrieb: On 12/2/2012 4:31 PM, Hans-Peter Diettrich wrote: [...] That's why I think that such libraries should be maintained by their own developers, so that all bug fixes and improvements become available immediately to the FPC users. Zlib is stable, not because

Re: [fpc-devel] Unhelpful error message

Mark Morgan Lloyd schrieb: What error message do you expect? Something that recognises that a message like <<< .mine originates from the project's chosen VCS, and that <<< is distinct from shl. +1 A concatenation of the *binary* "<" or "<<" operators, into "...", doesn't mak

Re: [fpc-devel] Please include gmp.dll in Win32 distribution of FPC 2.6.2 and later

Michael Van Canneyt schrieb: Is there not a native pascal solution for arbitrary precision math ? I seem to remember that there are several ones floating around, maybe we should simply include one of them. I'm not really happy with ports of sophisticated C libraries. When working on the Abbr

Re: [fpc-devel] win64 calling convention

Martin schrieb: Just to confirm my observations. (again trying to get pascal script to work) 64 bit windows procedure FOO(Sender: TSynEdit; const M: String; const P1, P2: TPoint); "const P1, P2: TPoint" versus "P1, P2: TPoint" if "const" is NOT used, then TPoint is put into a register if "c

Re: [fpc-devel] Are global variables guaranteed to be zero?

michael.vancann...@wisa.be schrieb: Are there cases where locals are set to a sane initial state, e.g. for strings and dynamic arrays? What about (references to) objects? Managed types are normally initialized. That means Ansistrings, UnicodeString, and COM interfaces and dynamic arrays (maybe

Re: [fpc-devel] Lazarus 1.0 and fpc 2.6 do not install on popular distributions

Giuliano Colla schrieb: The first problem is the rpm format: rpm's are generated with a recent version, which provides a higher compression level (lzma), but which isn't supported by the previous rpm versions. Using a graphic interface installer will not give any clue, just signaling an "unkno

Re: [fpc-devel] XML Components

Andrew Brunner schrieb: I just added this Prepare method to my database API. class function XML.IsInvalid(var Value:Byte):boolean; begin Result:=(Value<9) or (Value=11) or (Value=12) or ( (Value>13) and (Value<32)); end; [...] The question is, what is going to happen when the encoding is U

Re: [fpc-devel] FPC compiler architecture documentation

Mark Morgan Lloyd schrieb: However, what's needed /is/ the big picture, starting off with what's needed for a port (a PC, preferably running Linux, and a working FPC), where the modified source should be put (local svn, Lazarus CCR, or a branch of the main repository, and who to talk to and/or

Re: [fpc-devel] cross copiling x86_64 to i386 ?

Jonas Maebe schrieb: On 30 Aug 2012, at 23:50, Dimitrios Chr. Ioannidis wrote: "The MMX and floating-point stack registers (MM0-MM7/ST0-ST7) are preserved across context switches. There is no explicit calling convention for these registers. The use of these registers is strictly prohibited in

Re: [fpc-devel] cross copiling x86_64 to i386 ?

Martin schrieb: C:/FPC/tag_build_2_6_0/fpcsrc/compiler/ppcx64.exe -Ur -Xs -O2 -n -Fui386 -Fusystems -FuC:/fpc/tag_build_2_6_0/fpcsrc/rtl/units/x86_64-win64 -Fii386 -FE. -FUi386 /units/x86_64-win64 -dRELEASE -di386 -dGDB -dBROWSERLOG -Fux86 pp.pas fpcdefs.inc(160,2) Error: User defined: Cross-

Re: [fpc-devel] Recent added support for Observer pattern in FCL

Luiz Americo Pereira Camara schrieb: This is the purpose i intend to use (replace my implementation). Basically is a tree structure that needs to be observed. To avoid performance problems like having to parse all the tree when a change occurs i defined actions when a Child is added, deleted o

[fpc-devel] RTL Unicode support

Here's what I feel necessary for dealing with Unicode in all encodings. The Pos function demonstrates the problems with indexed string access. When automatic conversion of the string occurs, i.e. an AnsiString is converted into an UnicodeString (UTF-16), the returned index into the converted s

Re: [fpc-devel] Unicode in the RTL (my ideas)

Daniël Mantione schrieb: * There are no whitespace characters beyond widechar range. This means you can write a routine to split a string into words without bothing about surrogate pairs and remain fully UTF-16 compliant. How is this different for UTF-8? Your answer exactly demonstrates

Re: [fpc-devel] Unicode in the RTL (my ideas)

Daniël Mantione schrieb: Op Wed, 22 Aug 2012, schreef Felipe Monteiro de Carvalho: On Wed, Aug 22, 2012 at 9:36 PM, Martin Schreiber wrote: I am not talking about Unicode. I am talking about day by day programming of an average programmer where the live is easier with utf-16 than with utf-8.

Re: [fpc-devel] Unicode resource strings

Marco van de Voort schrieb: In our previous episode, Hans-Peter Diettrich said: this is a huge move for a native code compiler. If FPC will follow, this sounds like a lot of work. I don't see much work here. The code for handling interface references exists, it only has to be applied t

Re: [fpc-devel] Unicode in the RTL (my ideas)

Martin Schreiber schrieb: On Wednesday 22 August 2012 02:01:09 Hans-Peter Diettrich wrote: You still miss the point. Why deal with single characters, by index, when working with substrings also covers the single-character use? Why not if it is faster, simpler and more intuitive for beginners

Re: [fpc-devel] Unicode in the RTL (my ideas)

Ivanko B schrieb: Why deal with single characters, by index, when working with substrings also covers the single-character use? Possibly because it tens times as slower for multiple chars processed. Not really. Replacing the same amount of bytes can *always* be done in-pla

Re: [fpc-devel] Unicode in the RTL (my ideas)

Ivanko B schrieb: Do you mean replacing a character in an UCS-2/UCS-4 string can be implemented more efficiently than in an UTF-8/UTF-16 string? Sure, just scan the string char by char as array elements and replace as matches encounter. Like working with integer arrays. This applies only to

Re: [fpc-devel] Unicode resource strings

Graeme Geldenhuys schrieb: On 22 August 2012 00:54, Hans-Peter Diettrich wrote: IMO string conversion and CRC are mutually exclusive. Accessing a 100k of files (filenames to be exact) in a UTF-8 environment (Linux), which must all be stored in a UTF-16 string type. Filenames typically

Re: [fpc-devel] Unicode resource strings

Marco van de Voort schrieb: In our previous episode, Hans-Peter Diettrich said: utf8/16 -> ansi are a bit more involved. (since mapping many chars to few, naieve implementation requiring large lookupsets) A single 256 element array can be used for both directions. In Ansi to Unicode the c

Re: [fpc-devel] Unicode resource strings

Michael Schnell schrieb: On 08/21/2012 02:53 PM, Graeme Geldenhuys wrote: http://blogs.embarcadero.com/jtembarcadero/2012/08/20/xe3-and-beyond/ Other than politics, the big news regarding technology seems to be that Objects (or whatever) seem to get reference counted and thus I understand ".

<    1   2   3   4   5   6   7   8   9   10   >