Re: cpstrnew branch (was Re: [fpc-devel] Freepascal 2.4.0rc1 released)

In our previous episode, Tomas Hajny said: > > > supported codepages in the next version of MS Windows (or that they don't > > > support a different list in some special version, like a version for the > > > Chinese market) breaking your selection of "50 free values in Windows > > > range"? > > >

Re: cpstrnew branch (was Re: [fpc-devel] Freepascal 2.4.0rc1 released)

On 12 Nov 09, at 0:01, Jonas Maebe wrote: > On 11 Nov 2009, at 23:54, Tomas Hajny wrote: > > > Are character sets recognized by numeric values under Mac OS X? > > There are two ways to deal with them. One is libiconv, like on any > *nix platform (which, afaik, only supports string identifiers).

Re: cpstrnew branch (was Re: [fpc-devel] Freepascal 2.4.0rc1 released)

On 11 Nov 2009, at 23:54, Tomas Hajny wrote: Are character sets recognized by numeric values under Mac OS X? There are two ways to deal with them. One is libiconv, like on any *nix platform (which, afaik, only supports string identifiers). The other is CFString, which uses numeric values:

Re: cpstrnew branch (was Re: [fpc-devel] Freepascal 2.4.0rc1 released)

On 11 Nov 09, at 23:50, Jonas Maebe wrote: > On 11 Nov 2009, at 23:46, Tomas Hajny wrote: > > > That raises a question whether incompatibility between two FPC > > versions is better than incompatibility between FPC and Delphi > > (caused by tight connection between Delphi and one particular > > pl

Re: cpstrnew branch (was Re: [fpc-devel] Freepascal 2.4.0rc1 released)

On 11 Nov 2009, at 23:46, Tomas Hajny wrote: That raises a question whether incompatibility between two FPC versions is better than incompatibility between FPC and Delphi (caused by tight connection between Delphi and one particular platform)... Since they're working on a Mac OS X cross compi

Re: cpstrnew branch (was Re: [fpc-devel] Freepascal 2.4.0rc1 released)

On 11 Nov 09, at 20:53, Marco van de Voort wrote: > In our previous episode, Tomas Hajny said: > > >begin > > > encoding:=windowsencoding2nativeencoding[encoding]; > > >end; > > > > > > Delphi users would only have to define the fpc constants of (2) to their > > > respective windows co

Re: [fpc-devel] LLVM Backend?

- Original Message > From: Jonas Maebe > To: FPC developers' list > Sent: Wed, November 11, 2009 3:41:22 PM > Subject: Re: [fpc-devel] LLVM Backend? > > > Yes, it does, thanks. The main problem I see is that my approach would > require a > lot of initial work from my part (creating

Re: [fpc-devel] LLVM Backend?

On 11 Nov 2009, at 21:35, Samuel Crow wrote: It's not entirely clear to me yet how you see the result: an FPC frontend added to the LLVM project, or an LLVM backend added to the FPC project. I favour the latter, but a lot of what you talk about seems to be about the former. Or am I misund

Re: [fpc-devel] LLVM Backend?

- Original Message > From: Jonas Maebe > To: FPC developers' list > Sent: Wed, November 11, 2009 1:43:08 PM > Subject: Re: [fpc-devel] LLVM Backend? > -snip- > > > That's two problems, both fairly significant (although the latter is > definitely heavier than the former). Do you t

Re: cpstrnew branch (was Re: [fpc-devel] Freepascal 2.4.0rc1 released)

In our previous episode, Tomas Hajny said: > >begin > > encoding:=windowsencoding2nativeencoding[encoding]; > >end; > > > > Delphi users would only have to define the fpc constants of (2) to their > > respective windows codepages to keep the code working. > > Well... How do you make s

[fpc-devel] Re: cpstrnew branch

Graeme Geldenhuys : [Codepages] > Is FPC realistically going to implement all 2059 of those? I still think > even using the 63 most frequently used code page values should be ample > to keep FPC developers happy for quite some time. So which 63 out of the whole set are to be implemented to save t

Re: [fpc-devel] LLVM Backend?

On 11 Nov 2009, at 16:55, Samuel Crow wrote: - Original Message From: Jonas Maebe To: FPC developers' list Sent: Wed, November 11, 2009 5:03:52 AM Subject: Re: [fpc-devel] LLVM Backend? In a sense it's no problem if the LLVM backend doesn't support all targets that the other back

[fpc-devel] [patch] tBits

Hi Here is patch to tBits ans test program. Its repair FindnextBit. I also introduce FindNextRaw, based on it faster version FindNextBit can be done I can add: [code] function FindFirstBit; begin result:=findNextRaw(-1, state); end; function FindNextBit; begin result:=findNextRaw(findIndex, fi

Re: cpstrnew branch (was Re: [fpc-devel] Freepascal 2.4.0rc1 released)

On Wed, November 11, 2009 16:31, Marco van de Voort wrote: > In our previous episode, Tomas Hajny said: >> > >> > We might implement 1 or 2 of those. Most of them will however be >> > handled by libiconv, the Windows code page conversion APIs, or some >> > other external library (just like with the

Re: cpstrnew branch (was Re: [fpc-devel] Freepascal 2.4.0rc1 released)

On Wednesday 11 November 2009 15:57:28 Paul Ishenin wrote: > Martin Schreiber wrote: > > On Wednesday 11 November 2009 15:11:07 Florian Klaempfl wrote: > >> What rtl did you use? You need one from the branch. > > > > Compiling the cpstrnew rtl with fixes_2_4 does not work: > > 1. Build compiler exe

[fpc-devel] Request to merge revision 14145 for inclusion in FPC 2.4 ( DOM AVLTREE dependency removal )

With this revision, (fcl-xml) DOM no longer depends on TAVLTree, and so (fcl-xml) DOM can be safely used in a multi threaded environment. For server side development, specialy web services projects, this is a enablement. Best regards. -- Inoussa O. ___

Re: [fpc-devel] LLVM Backend?

- Original Message > From: Jonas Maebe > To: FPC developers' list > Sent: Wed, November 11, 2009 5:03:52 AM > Subject: Re: [fpc-devel] LLVM Backend? > > > On 11 Nov 2009, at 04:29, Samuel Crow wrote: > > > As noted in other messages on the list, the LLVM-FPC compiler would be > >

Re: [fpc-devel] XML DOM thread safety

2009/11/11 Sergei Gorelkin : > Inoussa OUEDRAOGO пишет: > > (a long message skipped) > > Rather that writing that much, you'd better simply bug me to speed it up :-) > Anyway, done in r14145. Thank you very much ! I will now call for a merge for FPC 2.4. Again, Thank you very much ! -- Inoussa

Re: cpstrnew branch (was Re: [fpc-devel] Freepascal 2.4.0rc1 released)

In our previous episode, Tomas Hajny said: > > > > We might implement 1 or 2 of those. Most of them will however be > > handled by libiconv, the Windows code page conversion APIs, or some > > other external library (just like with the current widestring manager). > > Nevertheless: is e.g. ISO 8859

Re: cpstrnew branch (was Re: [fpc-devel] Freepascal 2.4.0rc1 released)

Vincent Snijders wrote: This fails here with the error Martin got too: Compiling ../unix/cwstring.pp Not Florian nor me touched linux yet. Best regards, Paul Ishenin. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.o

Re: cpstrnew branch (was Re: [fpc-devel] Freepascal 2.4.0rc1 released)

Paul Ishenin schreef: Martin Schreiber wrote: On Wednesday 11 November 2009 15:11:07 Florian Klaempfl wrote: What rtl did you use? You need one from the branch. Compiling the cpstrnew rtl with fixes_2_4 does not work: 1. Build compiler executable with 2.2.4 / 2.4.0 2. Build RTL wit

Re: cpstrnew branch (was Re: [fpc-devel] Freepascal 2.4.0rc1 released)

On Wed, November 11, 2009 14:10, Jonas Maebe wrote: > On 11 Nov 2009, at 13:49, Graeme Geldenhuys wrote: > >> Is FPC realistically going to implement all 2059 of those? > > We might implement 1 or 2 of those. Most of them will however be > handled by libiconv, the Windows code page conversion APIs,

Re: cpstrnew branch (was Re: [fpc-devel] Freepascal 2.4.0rc1 released)

Vincent Snijders schreef: Paul Ishenin schreef: Martin Schreiber wrote: On Wednesday 11 November 2009 15:11:07 Florian Klaempfl wrote: What rtl did you use? You need one from the branch. Compiling the cpstrnew rtl with fixes_2_4 does not work: 1. Build compiler executable with 2.2

Re: cpstrnew branch (was Re: [fpc-devel] Freepascal 2.4.0rc1 released)

Paul Ishenin schreef: Martin Schreiber wrote: On Wednesday 11 November 2009 15:11:07 Florian Klaempfl wrote: What rtl did you use? You need one from the branch. Compiling the cpstrnew rtl with fixes_2_4 does not work: 1. Build compiler executable with 2.2.4 / 2.4.0 2. Build RTL wit

Re: cpstrnew branch (was Re: [fpc-devel] Freepascal 2.4.0rc1 released)

Martin Schreiber wrote: On Wednesday 11 November 2009 15:11:07 Florian Klaempfl wrote: What rtl did you use? You need one from the branch. Compiling the cpstrnew rtl with fixes_2_4 does not work: 1. Build compiler executable with 2.2.4 / 2.4.0 2. Build RTL with the new executable 3

Re: cpstrnew branch (was Re: [fpc-devel] Freepascal 2.4.0rc1 released)

On Wednesday 11 November 2009 15:11:07 Florian Klaempfl wrote: > > What rtl did you use? You need one from the branch. Compiling the cpstrnew rtl with fixes_2_4 does not work: " Free Pascal Compiler version 2.3.1 [2009/11/01] for i386 Copyright (c) 1993-2009 by Florian Klaempfl Target OS: Linux fo

Re: [fpc-devel] LLVM Backend?

Hello Michael, The MIPS32 code for LLVM's code generator is out-of-date but salvageable. If you're familiar with C++ I'd recommend anybody use LLVM for its massive optimizations, documentation and support classes. If you want C/C++/Objective C compiler as well as other compilers working on yo

Re: [fpc-devel] XML DOM thread safety

Inoussa OUEDRAOGO пишет: (a long message skipped) Rather that writing that much, you'd better simply bug me to speed it up :-) Anyway, done in r14145. Sergei ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman

Re: cpstrnew branch (was Re: [fpc-devel] Freepascal 2.4.0rc1 released)

Martin Schreiber schrieb: > On Wednesday 11 November 2009 13:47:43 Florian Klaempfl wrote: >>> I try to prove the exciting statement. How can I build a startup compiler >>> for the cpstrnew branch or >> I use the 2.2.4/2.4.0 ide to build the compiler, so make in the cpstrnew >> branch compiler dir

Re: cpstrnew branch (was Re: [fpc-devel] Freepascal 2.4.0rc1 released)

On Wed, November 11, 2009 13:56, Graeme Geldenhuys wrote: > Tomas Hajny wrote: >> >> I'm afraid that your assumption about the number of codepages is >> incorrect. The MIBENUM value defined in list at >> http://www.iana.org/assignments/character-sets goes up to 2059 at the >> moment. > > I just dou

Re: cpstrnew branch (was Re: [fpc-devel] Freepascal 2.4.0rc1 released)

On Wed, November 11, 2009 13:56, Graeme Geldenhuys wrote: > Tomas Hajny wrote: >> >> I'm afraid that your assumption about the number of codepages is >> incorrect. The MIBENUM value defined in list at >> http://www.iana.org/assignments/character-sets goes up to 2059 at the >> moment. > > I just dou

Re: cpstrnew branch (was Re: [fpc-devel] Freepascal 2.4.0rc1 released)

On Wednesday 11 November 2009 13:47:43 Florian Klaempfl wrote: > > I try to prove the exciting statement. How can I build a startup compiler > > for the cpstrnew branch or > > I use the 2.2.4/2.4.0 ide to build the compiler, so make in the cpstrnew > branch compiler dir should work using 2.2.4/2.4.

Re: cpstrnew branch (was Re: [fpc-devel] Freepascal 2.4.0rc1 released)

Tomas Hajny wrote: > > I'm afraid that your assumption about the number of codepages is > incorrect. The MIBENUM value defined in list at > http://www.iana.org/assignments/character-sets goes up to 2059 at the > moment. I just double checked. That number is "in theory" only. There are not nearly

Re: cpstrnew branch (was Re: [fpc-devel] Freepascal 2.4.0rc1 released)

On 11 Nov 2009, at 13:49, Graeme Geldenhuys wrote: Is FPC realistically going to implement all 2059 of those? We might implement 1 or 2 of those. Most of them will however be handled by libiconv, the Windows code page conversion APIs, or some other external library (just like with the cur

Re: cpstrnew branch (was Re: [fpc-devel] Freepascal 2.4.0rc1 released)

Tomas Hajny wrote: > > I'm afraid that your assumption about the number of codepages is > incorrect. The MIBENUM value defined in list at > http://www.iana.org/assignments/character-sets goes up to 2059 at the > moment. Is FPC realistically going to implement all 2059 of those? I still think eve

Re: [fpc-devel] Dynamically Loading Libraries

Jonas Maebe wrote: procedure proc; external 'libname' name 'proc'; denotes a function that's dynamically loaded implicitly, while procedure proc; external name 'proc'; denotes a static linked function. In my opinion that seems like the only logical solution. Explicit dynamic loading will of

Re: cpstrnew branch (was Re: [fpc-devel] Freepascal 2.4.0rc1 released)

Martin Schreiber wrote: I try to prove the exciting statement. How can I build a startup compiler for the cpstrnew branch or how to compile the cpstrnew branch? I use the next bat file in the compiler dir: [copy of my bat] @echo off c:\programming\cpstrnew\bin\i386-win32\make.exe clean all O

Re: cpstrnew branch (was Re: [fpc-devel] Freepascal 2.4.0rc1 released)

On Wed, November 11, 2009 13:42, Tomas Hajny wrote: > On Wed, November 11, 2009 09:58, Graeme Geldenhuys wrote: >> Florian Klaempfl wrote: >>> >>> The constant encoding the code page requires 2 bytes, >> >> Could those become enum values instead, which means you can store up to >> 255 different cod

Re: cpstrnew branch (was Re: [fpc-devel] Freepascal 2.4.0rc1 released)

On 11 Nov 2009, at 13:47, Micha Nelissen wrote: Jonas Maebe wrote: No, 25 bytes. The plain ansistring 'a' is already 17 bytes on x86_64 platforms today. Is that because of sizeint? Yes. Wouldn't longint be long enough? If you'd want to limit the length to 2GB on 64 bit systems. I also

Re: cpstrnew branch (was Re: [fpc-devel] Freepascal 2.4.0rc1 released)

Martin Schreiber schrieb: > On Tuesday 10 November 2009 19:08:45 Florian Klaempfl wrote: >> Martin Schreiber schrieb: >>> On Tuesday 10 November 2009 18:33:54 Florian Klaempfl wrote: > Did you look into the code in cpstrnew branch? I did. And which changes are exactly the reason for your c

Re: cpstrnew branch (was Re: [fpc-devel] Freepascal 2.4.0rc1 released)

Jonas Maebe wrote: Does that mean in the cpstrnew branch and on x86_64 systems, the UTF-8 string 'a' will be 9 bytes long? No, 25 bytes. The plain ansistring 'a' is already 17 bytes on x86_64 platforms today. Is that because of sizeint? Wouldn't longint be long enough? Micha ___

Re: cpstrnew branch (was Re: [fpc-devel] Freepascal 2.4.0rc1 released)

On Wed, November 11, 2009 09:58, Graeme Geldenhuys wrote: > Florian Klaempfl wrote: >> >> The constant encoding the code page requires 2 bytes, > > Could those become enum values instead, which means you can store up to > 255 different code-page types in 1 byte. 255 should be sufficient to > cover

Re: cpstrnew branch (was Re: [fpc-devel] Freepascal 2.4.0rc1 released)

On Tuesday 10 November 2009 19:08:45 Florian Klaempfl wrote: > Martin Schreiber schrieb: > > On Tuesday 10 November 2009 18:33:54 Florian Klaempfl wrote: > >>> Did you look into the code in cpstrnew branch? I did. > >> > >> And which changes are exactly the reason for your concerns? > > > > More ch

Re: [fpc-devel] Dynamically Loading Libraries

On 10 Nov 2009, at 23:24, Jeppe Johansen wrote: What about saying that procedure proc; external 'libname' name 'proc'; denotes a function that's dynamically loaded implicitly, while procedure proc; external name 'proc'; denotes a static linked function. In my opinion that seems like the on

[fpc-devel] XML DOM thread safety

Hi I would like to point out ( again, the third time ) that up to now ( I just checked out 2.4-rc1 and trunk ) there is _no safe_ way to use the "fcl-xml" package in a multi threaded environment. I mean, even if your xml DOM instances are private to their thread, _not accessed_ by other threads, u

Re: [fpc-devel] Dynamically Loading Libraries

On 11 Nov 2009, at 11:54, Marco van de Voort wrote: In our previous episode, Jeppe Johansen said: This syntax is not possible. The external 'xxx' name 'proc' is there for a reason, for systems with multiple linker namespaces. Moreover there is already an enormous codebase that uses this.

Re: [fpc-devel] Dynamically Loading Libraries

Regarding a similar subject, I found an article by Hallvards Vassbotn showing a method to delay load dlls in Delphi, its usage is pretty similar to static linking, but the library is loaded on demand (without explicitly calling LoadLibrary). This is a short version: http://hallvards.blogspot.c

Re: [fpc-devel] LLVM Backend?

On 11 Nov 2009, at 12:24, Michael Schnell wrote: Jonas Maebe wrote: b. the dragonegg approach (http://dragonegg.llvm.org/), where you make use of the support in an existing compiler (again GCC in this case) for abstract code generator support to emit LLVM assembler/bitcode rather than mach

Re: [fpc-devel] LLVM Backend?

Jonas Maebe wrote: > b. the dragonegg approach (http://dragonegg.llvm.org/), where you make > use of the support in an existing compiler (again GCC in this case) for > abstract code generator support to emit LLVM assembler/bitcode rather > than machine code For my upcoming project: I (of course) d

Re: [fpc-devel] LLVM Backend?

On 11 Nov 2009, at 04:29, Samuel Crow wrote: The IRBuilder class http://llvm.org/doxygen/classllvm_1_1IRBuilder.html is as stable as the instruction set it builds and is maintained as such since it is used by Clang, LLVM-GCC and other frontends. Ok, that would be fine then. The only proble

Re: [fpc-devel] LLVM Backend?

Samuel Crow wrote: > I'm looking forward to the challenges of this project. I am planing for another project: doing an FPC compiler for the NIOS processor (which is similar to MIPS32) on a Linux target. Do you think it's viable to consider LLVM instead of trying to modify the "native" ARM FPC co

Re: [fpc-devel] Dynamically Loading Libraries

In our previous episode, Jeppe Johansen said: > >> procedure proc; external name 'proc'; > >> denotes a static linked function. > >> > > > > This syntax is not possible. The external 'xxx' name 'proc' is there for a > > reason, > > for systems with multiple linker namespaces. Moreover the

Re: [fpc-devel] Dynamically Loading Libraries

Marco van de Voort wrote: In our previous episode, Jeppe Johansen said: -Ivo Steinmann What about saying that procedure proc; external 'libname' name 'proc'; denotes a function that's dynamically loaded implicitly, while

Re: cpstrnew branch (was Re: [fpc-devel] Freepascal 2.4.0rc1 released)

On 11 Nov 2009, at 11:04, Michael Schnell wrote: What about case sensitivity with "if str1=str2 then ..." ? The "=" operator for strings has always performed a simply byte-wise comparison until now, and presumably keeps acting the same in Delphi 2009 with the new UnicodeStrings. Custom st

Re: cpstrnew branch (was Re: [fpc-devel] Freepascal 2.4.0rc1 released)

In our previous episode, Martin Schreiber said: [ Charset ISO-8859-1 unsupported, converting... ] > On Tuesday 10 November 2009 21:38:33 Marco van de Voort wrote: > > > > The only problem is the db-aware part and the few other widgets that can > > have 10 elements and more, like treeview. There

Re: [fpc-devel] Dynamically Loading Libraries

In our previous episode, Jeppe Johansen said: > > > > -Ivo Steinmann > > > > > What about saying that > procedure proc; external 'libname' name 'proc'; > denotes a function that's dynamically loaded implicitly, while > procedure proc;

Re: cpstrnew branch (was Re: [fpc-devel] Freepascal 2.4.0rc1 released)

Jonas Maebe wrote: > RawWordString and RawDWordString don't make any sense. All Strings with > 32 bit elements are UTF-32. What about case sensitivity with "if str1=str2 then ..." ? > Those with 16 bit elements can't be UTF-16 > big or little endian, or UCS-2, but I can't see why any programmer

Re: cpstrnew branch (was Re: [fpc-devel] Freepascal 2.4.0rc1 released)

Michael Schnell wrote: > > - RawDWordString > - RawWordString > - RawByteString Edit: add RawQWordString. OTHO I just learned that all of them are called "RawByteString" (Thus IMHO just "RawString" is the more appropriate name) and the character size (= 1, 2, 4, or 8) is handled separately.

Re: cpstrnew branch (was Re: [fpc-devel] Freepascal 2.4.0rc1 released)

On 11 Nov 2009, at 10:52, Jonas Maebe wrote: Those with 16 bit elements can't be UTF-16 big or little endian, or UCS-2, *can* be, of course Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listin

Re: cpstrnew branch (was Re: [fpc-devel] Freepascal 2.4.0rc1 released)

On 11 Nov 2009, at 10:37, Michael Schnell wrote: Of course that is true. So IMHO (at least) theses encoding types should be supported: Please read this document first: http://edn.embarcadero.com/article/38980 - RawDWordString - RawWordString (handled like good old WideStrings ?(*) ) - Raw

Re: cpstrnew branch (was Re: [fpc-devel] Freepascal 2.4.0rc1 released)

Florian Klaempfl wrote: > > No. RawByteString means simply: encoding unknown, the string is just a > couple of bytes (which could also form words or dwords) described by the > the encoding and char size fields. I see. Bit this is exactly what I meant: RawByteString, RawWordString and RawDWordSt

Re: cpstrnew branch (was Re: [fpc-devel] Freepascal 2.4.0rc1 released)

On 11 Nov 2009, at 10:07, Graeme Geldenhuys wrote: Sergei Gorelkin wrote: It won't. 4 bytes will be used anyway because of alignment. On x86_64, it is even 8 bytes. Does that mean in the cpstrnew branch and on x86_64 systems, the UTF-8 string 'a' will be 9 bytes long? No, 25 bytes. The pl

Re: cpstrnew branch (was Re: [fpc-devel] Freepascal 2.4.0rc1 released)

Sergei Gorelkin wrote: > > It won't. 4 bytes will be used anyway because of alignment. > On x86_64, it is even 8 bytes. Does that mean in the cpstrnew branch and on x86_64 systems, the UTF-8 string 'a' will be 9 bytes long? Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit

Re: cpstrnew branch (was Re: [fpc-devel] Freepascal 2.4.0rc1 released)

Florian Klaempfl wrote: > > The constant encoding the code page requires 2 bytes, Could those become enum values instead, which means you can store up to 255 different code-page types in 1 byte. 255 should be sufficient to cover all available code-page constants (I think). Or couldn't that maybe

Re: cpstrnew branch (was Re: [fpc-devel] Freepascal 2.4.0rc1 released)

Marco van de Voort wrote: > While I think it would be best to use native encoding on all platforms as > much as possible, that is an opinion. However not using native encoding for > general processing is nuts. So we need the UTF8 type anyway. > Of course that is true. So IMHO (at least) theses en

Re: cpstrnew branch (was Re: [fpc-devel] Freepascal 2.4.0rc1 released)

Marco van de Voort wrote: > That is probably solvable (... only translating at the moment of > viewing ...). I feel that this is exactly what D2009 Strings are a perfect tool for: conversions are automatically done when necessary and not "just in case". I suppose that there are means provided to t

Re: cpstrnew branch (was Re: [fpc-devel] Freepascal 2.4.0rc1 released)

Michael Schnell schrieb: > Florian Klaempfl wrote: >> No other string types being involved especially things like RawByteString. > > If you additionally implement the encoding Type RawWordString, Martin > should be happy. No. RawByteString means simply: encoding unknown, the string is just a coup

Re: cpstrnew branch (was Re: [fpc-devel] Freepascal 2.4.0rc1 released)

Michael Schnell schrieb: > Martin Schreiber wrote: >> OK, so you say that the processing of the new and the current UnicodeString >> and therefore the RTL and compiler procedures are identical with exception >> of >> the initialization of 4 bytes with a constant? Now that is exciting. > > Of co

Re: cpstrnew branch (was Re: [fpc-devel] Freepascal 2.4.0rc1 released)

Florian Klaempfl wrote: > No other string types being involved especially things like RawByteString. If you additionally implement the encoding Type RawWordString, Martin should be happy. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.or

Re: cpstrnew branch (was Re: [fpc-devel] Freepascal 2.4.0rc1 released)

Martin Schreiber wrote: > OK, so you say that the processing of the new and the current UnicodeString > and therefore the RTL and compiler procedures are identical with exception of > the initialization of 4 bytes with a constant? Now that is exciting. Of course with any operation that uses two

Re: cpstrnew branch (was Re: [fpc-devel] Freepascal 2.4.0rc1 released)

Martin Schreiber wrote: > Did you look into the code in cpstrnew branch? Not yet (sitting behind a firewall I had major problems with using the revision control system. I do use GIT for other projects so I'll recheck some day soon.) > I did. So you do suggest that this code is not optimized on

Re: cpstrnew branch (was Re: [fpc-devel] Freepascal 2.4.0rc1 released)

Graeme Geldenhuys wrote: I have not looked at the cpstrnew branch, but what is the 4 bytes used for in each string? Couldn't the individual bits in 1 byte value be used? That will reduce the extra memory overhead by 75%? It won't. 4 bytes will be used anyway because of alignment. On x86_64, it

Re: cpstrnew branch (was Re: [fpc-devel] Freepascal 2.4.0rc1 released)

Graeme Geldenhuys schrieb: > Florian Klaempfl wrote: >>> and therefore the RTL and compiler procedures are identical with exception >>> of >>> the initialization of 4 bytes with a constant? >> Well, two times two byte ;) > > I have not looked at the cpstrnew branch, but what is the 4 bytes used

Re: cpstrnew branch (was Re: [fpc-devel] Freepascal 2.4.0rc1 released)

Florian Klaempfl wrote: >> and therefore the RTL and compiler procedures are identical with exception >> of >> the initialization of 4 bytes with a constant? > > Well, two times two byte ;) I have not looked at the cpstrnew branch, but what is the 4 bytes used for in each string? Couldn't the i

Re: cpstrnew branch (was Re: [fpc-devel] Freepascal 2.4.0rc1 released)

thaddy wrote: > Just to make a small point: the choice for UTF16 was made because of > market reasons, not technical ones. Chinese Korean, Japanese markets are > important for Delphi. Try to figure out how to fit that in UTF8. Just a > thought. I have to agree with Marco there. Delphi simply fo

Re: cpstrnew branch (was Re: [fpc-devel] Freepascal 2.4.0rc1 released)

Martin Schreiber wrote: > It supports now Linux x86-64. I used about 110 hours for the adaption. > Problem > is gdb and dwarf on x86-64 (display of var parameters) and freezing of the > application if compiled with -gl in case of an exception. I can't understand > that Lazarus lives with this s