Re: [fpc-pascal] using static linking of dylib in mac 10.5
On 22 Oct 2008, at 05:05, Guru Kathiresan wrote:
Thanks for the reply. That seems to work, but I think there is a bug
in the
FPC. When I do a {$linklib myfile.dylib} , it is not picking up the
myfile.dylib, the compiler is looking for libmyfile.so . I had to
rename the
library from myfile.dylib to libmyfile.so .
Your library was simply named wrongly if it was called myfile.dylib.
If you want the compiler and linker to find a dynamic library, its
name must start with lib, so libmyfile.dylib (because to the linker
you can only say -lmyfile, and then it automatically searches for
libmyfile.dylib; maybe it also searches for libmyfile.so nowadays, I
don't know).
Jonas
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] 2.2.2 INSTALL PROBLEM
Hey. I just went inside the file and deleted all the -Opentium3 lines and it worked. Not really sure about the reason but it worked =). Cheers Lude Jonas Maebe-2 wrote: On 15 Aug 2008, at 09:39, Michael Van Canneyt wrote: On Fri, 15 Aug 2008, John Youngquist wrote: I also routinely see unusual behavior during debug. In routine debugging suddenly breakpoints don't break anymore. I exit FPC and restart to return to normal operation. SImilarly the watching of record structures just quits. Restart fixes that to. I was hoping 2.2.2 might fix these problems. But it won't even run for me. The debug problem is not really in our hands. We use the GNU debugger, and if the GNU team (not exactly a cheering crowd of pascal fans) breaks things for Pascal, then we are pretty much powerless. It is extremely unlikely the above symptoms (both the ones described for 2.2.0 and 2.2.2) have anything to do whatsoever with Pascal support in gdb. It sounds much more like bugs in the internal debugger interface of the IDE (and as for the 2.2.2 symptom, I read that as the 2.2.2 IDE won't even run for me). in fact, gdb's Pascal support has been extremely stable (I've seen less than a handful regressions during the last 10 years). And that while the first basic Pascal test cases for gdb were only added during the last couple of years (by Pierre). Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal -- View this message in context: http://www.nabble.com/2.2.2-INSTALL-PROBLEM-tp18982659p20089734.html Sent from the Free Pascal - General mailing list archive at Nabble.com. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] fpc assember does not generate short jumps.
I have an assembler procedure of about a 1500 lines of code. The problem is the jumps are generated with absolute addresses only, even if I explicitly specify short postfix. Why is it? The code size is critical for me. I am using lazarus with fpc 2.2.2. Example code: sub eax,dword ptr [esp] add esp,04h cmp eax,0FFFh jbe short @not_traced // JBE 0xABSOLUTE_ADDRESS GENERATED - WHY???!!! popad popad retn @not_traced: Any suggestions? Thank you. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] fpc assember does not generate short jumps.
On 22 Oct 2008, at 10:46, Саша Иваненко wrote: I have an assembler procedure of about a 1500 lines of code. The problem is the jumps are generated with absolute addresses only, even if I explicitly specify short postfix. Why is it? The code size is critical for me. I am using lazarus with fpc 2.2.2. Example code: sub eax,dword ptr [esp] add esp,04h cmp eax,0FFFh jbe short @not_traced // JBE 0xABSOLUTE_ADDRESS GENERATED - WHY???!!! It's not an absolute address, but a 32 bit relative address. popad popad retn @not_traced: Any suggestions? Thank you. You can try using the external assembler (-Aas). And file a bug report against the internal one (although I thought there was already a bug report about this, I can't find it immediately) Jonas___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Delphi / FPC and UTF8 BOM
In our previous episode, Jonas Maebe said: There has been a lot of discussion about this problem. What happens is that FPC wishes to always have ansistrings holding system locale encoded strings, it's impossible to have strings which store utf-8 data as far as FPC is concerned. And the reason is that a) if you mix system and non-system encodings in ansistrings, then a bunch of string conversions between ansistrings and widestrings will go horribly wrong b) if you only use a particular non-system encoding for ansistrings, then interfacing with OS routines will break down completely It is possible to solve b) by manually adding necessary extra string conversions everywhere in the RTL where ansistrings are passed to OS routines, but that is a lot of work (both to implement and to maintain) and very error prone. Then it's indeed much cleaner to simply introduce a new string type which does not have to be compatible with the OS encoding. The solution of Tiburon is the same as Florian's original solution for the multi unicode string type TUnicodeString (that now is still UTF16 only): add an encoding field to ansistring, and alter ansistring declaration with an encoding type: Type TUtf8String = ansistring (cp_UTF8); This way you can explicitely flag anything internal as UTF-8, and communicate with the outside 1-byte world using the native codepage (which might be UTF-8 too, if desired) The solution has Windows written all over it (including viewer UTF-8 as a codepage), but it has merits IMHO. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Delphi / FPC and UTF8 BOM
Then it's indeed much cleaner to simply introduce a new string type which does not have to be compatible with the OS encoding. Agree!. It's an illusion that it's possible to hide the complexitiy of different string encodings from the programmer. Instead, such tries always lead to a disaster when the user tests his programs with simple strings which work and then encounters the problems late in the project when unusual characters are used. Better confront the programmer with it right from the start so he knows what to expect. Jürgen Hestermann. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Delphi / FPC and UTF8 BOM
On Wednesday 22 October 2008 12.33:59 Marco van de Voort wrote: The solution of Tiburon is the same as Florian's original solution for the multi unicode string type TUnicodeString (that now is still UTF16 only): add an encoding field to ansistring, and alter ansistring declaration with an encoding type: Type TUtf8String = ansistring (cp_UTF8); This way you can explicitely flag anything internal as UTF-8, and communicate with the outside 1-byte world using the native codepage (which might be UTF-8 too, if desired) The solution has Windows written all over it (including viewer UTF-8 as a codepage), but it has merits IMHO. Are you sure about the encoding field for every string instance? It could be done by compiler magic and an encoding field in the typeinfo too? Martin ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Delphi / FPC and UTF8 BOM
In our previous episode, Martin Schreiber said: The solution has Windows written all over it (including viewer UTF-8 as a codepage), but it has merits IMHO. Are you sure about the encoding field for every string instance? Yes. It could be done by compiler magic and an encoding field in the typeinfo too? No, since then the runtime routines must be overloaded again, for each compiler magic'ed type (all codepages +UTF-8, and another two). A runtime routine must be able to detect what kind of string type it receives, or you need a runtime routine per type. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Delphi / FPC and UTF8 BOM
On Wednesday 22 October 2008 13.31:41 Marco van de Voort wrote: In our previous episode, Martin Schreiber said: The solution has Windows written all over it (including viewer UTF-8 as a codepage), but it has merits IMHO. Are you sure about the encoding field for every string instance? Yes. It could be done by compiler magic and an encoding field in the typeinfo too? No, since then the runtime routines must be overloaded again, for each compiler magic'ed type (all codepages +UTF-8, and another two). A runtime routine must be able to detect what kind of string type it receives, or you need a runtime routine per type. Or the compiler adds the conversion to the function call because at compiletime the encoding of both types are known. Delphi converts always to an intermediate utf-16 AFAIK. Martin ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Delphi / FPC and UTF8 BOM
In our previous episode, Martin Schreiber said: No, since then the runtime routines must be overloaded again, for each compiler magic'ed type (all codepages +UTF-8, and another two). A runtime routine must be able to detect what kind of string type it receives, or you need a runtime routine per type. Or the compiler adds the conversion to the function call because at compiletime the encoding of both types are known. Delphi converts always to an intermediate utf-16 AFAIK. No, not always. It often does so for actual processing, but not when it passes to a procedure that simply passes the string on to the next. And that is the problem in your case. You can't declare a procedure to accept a general ansistring, just to pass it on, since then the type info is lost. Having a general ansistring limits the conversion when passed to procedures that only accept a certain encoding, and to the (typically leaf-) procedures that do actual processing. Moreover, the 4 bytes encoding are not a real problem. If it can save a conversion here and there, it is already better. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Record Method and Operators
Hi, Im wondering if FPC Team have plans to support Record Methods/Operators in future versions of FPC I read the actual Future plans and the most closed item is RTL:: More compatibility with later Delphi versions. But it do not means that records can be changed. I want to implement my ValueTypes using record with implicit operators and constructor/destructor, like this code written by a friend, Lee Nover. TSpecifier = record S: AnsiString; WS: WideString; Intf: IInterface; class operator Implicit(const S: AnsiString): TSpecifier; class operator Implicit(const C: Cardinal): TSpecifier; class operator Implicit(const D: Double): TSpecifier; class operator Implicit(const I: Integer): TSpecifier; class operator Implicit(const I64: Int64): TSpecifier; class operator Implicit(const V: TValue): TSpecifier; class operator Implicit(const WS: WideString): TSpecifier; class operator Implicit(const Intf: IInterface): TSpecifier; class operator Implicit(const Spec: TSpecifier): AnsiString; class operator Implicit(const Spec: TSpecifier): Cardinal; class operator Implicit(const Spec: TSpecifier): Double; class operator Implicit(const Spec: TSpecifier): Integer; class operator Implicit(const Spec: TSpecifier): Int64; class operator Implicit(const Spec: TSpecifier): TValue; class operator Implicit(const Spec: TSpecifier): WideString; class operator Implicit(const Spec: TSpecifier): IInterface; case NativeType: Integer of varInteger: (I: Integer); varInt64: (I64: Int64); varLongWord: (C: Cardinal); varDouble: (D: Double); varObject: (O: TValue); end; My plans is to have a single framework compatible with Delphi 2007/2009 and FPC, so Ill not use some D2009 only resources, but implicit operators make the live of users very better to write less and better code. Can I have any hope about this subject? -- Cesar Romero http://blogs.liws.com.br/cesar http://blogs.liws.com.br/cesar/?feed=rss2 ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Record Method and Operators
Cesar Romero schrieb: Hi, Im wondering if FPC Team have plans to support Record Methods/Operators in future versions of FPC I read the actual Future plans and the most closed item is RTL:: More compatibility with later Delphi versions. But it do not means that records can be changed. I want to implement my ValueTypes using record with implicit operators and constructor/destructor, like this code written by a friend, Lee Nover. TSpecifier = record S: AnsiString; WS: WideString; Intf: IInterface; class operator Implicit(const S: AnsiString): TSpecifier; class operator Implicit(const C: Cardinal): TSpecifier; class operator Implicit(const D: Double): TSpecifier; class operator Implicit(const I: Integer): TSpecifier; class operator Implicit(const I64: Int64): TSpecifier; class operator Implicit(const V: TValue): TSpecifier; class operator Implicit(const WS: WideString): TSpecifier; class operator Implicit(const Intf: IInterface): TSpecifier; class operator Implicit(const Spec: TSpecifier): AnsiString; class operator Implicit(const Spec: TSpecifier): Cardinal; class operator Implicit(const Spec: TSpecifier): Double; class operator Implicit(const Spec: TSpecifier): Integer; class operator Implicit(const Spec: TSpecifier): Int64; class operator Implicit(const Spec: TSpecifier): TValue; class operator Implicit(const Spec: TSpecifier): WideString; class operator Implicit(const Spec: TSpecifier): IInterface; case NativeType: Integer of varInteger: (I: Integer); varInt64: (I64: Int64); varLongWord: (C: Cardinal); varDouble: (D: Double); varObject: (O: TValue); end; My plans is to have a single framework compatible with Delphi 2007/2009 and FPC, so Ill not use some D2009 only resources, but implicit operators make the live of users very better to write less and better code. Can I have any hope about this subject? What does it prevent you from using FPC's operator overloading capabilities to do so which has FPC for 10 years? ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Record Method and Operators
Florian Klaempfl escreveu: Cesar Romero schrieb: Hi, Im wondering if FPC Team have plans to support Record Methods/Operators in future versions of FPC I read the actual Future plans and the most closed item is RTL:: More compatibility with later Delphi versions. But it do not means that records can be changed. I want to implement my ValueTypes using record with implicit operators and constructor/destructor, like this code written by a friend, Lee Nover. TSpecifier = record S: AnsiString; WS: WideString; Intf: IInterface; class operator Implicit(const S: AnsiString): TSpecifier; class operator Implicit(const C: Cardinal): TSpecifier; class operator Implicit(const D: Double): TSpecifier; class operator Implicit(const I: Integer): TSpecifier; class operator Implicit(const I64: Int64): TSpecifier; class operator Implicit(const V: TValue): TSpecifier; class operator Implicit(const WS: WideString): TSpecifier; class operator Implicit(const Intf: IInterface): TSpecifier; class operator Implicit(const Spec: TSpecifier): AnsiString; class operator Implicit(const Spec: TSpecifier): Cardinal; class operator Implicit(const Spec: TSpecifier): Double; class operator Implicit(const Spec: TSpecifier): Integer; class operator Implicit(const Spec: TSpecifier): Int64; class operator Implicit(const Spec: TSpecifier): TValue; class operator Implicit(const Spec: TSpecifier): WideString; class operator Implicit(const Spec: TSpecifier): IInterface; case NativeType: Integer of varInteger: (I: Integer); varInt64: (I64: Int64); varLongWord: (C: Cardinal); varDouble: (D: Double); varObject: (O: TValue); end; My plans is to have a single framework compatible with Delphi 2007/2009 and FPC, so Ill not use some D2009 only resources, but implicit operators make the live of users very better to write less and better code. Can I have any hope about this subject? What does it prevent you from using FPC's operator overloading capabilities to do so which has FPC for 10 years? ___ I guess... nothing, but I cant find any docs until now, I googled about that and search on fpc site. If I can find docs about that and it can work as I expect, Ill use of cource. -- Cesar Romero http://blogs.liws.com.br/cesar http://blogs.liws.com.br/cesar/?feed=rss2 ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Record Method and Operators
Florian Klaempfl escreveu: Cesar Romero schrieb: Hi, Im wondering if FPC Team have plans to support Record Methods/Operators in future versions of FPC I read the actual Future plans and the most closed item is RTL:: More compatibility with later Delphi versions. But it do not means that records can be changed. I want to implement my ValueTypes using record with implicit operators and constructor/destructor, like this code written by a friend, Lee Nover. TSpecifier = record S: AnsiString; WS: WideString; Intf: IInterface; class operator Implicit(const S: AnsiString): TSpecifier; class operator Implicit(const C: Cardinal): TSpecifier; class operator Implicit(const D: Double): TSpecifier; class operator Implicit(const I: Integer): TSpecifier; class operator Implicit(const I64: Int64): TSpecifier; class operator Implicit(const V: TValue): TSpecifier; class operator Implicit(const WS: WideString): TSpecifier; class operator Implicit(const Intf: IInterface): TSpecifier; class operator Implicit(const Spec: TSpecifier): AnsiString; class operator Implicit(const Spec: TSpecifier): Cardinal; class operator Implicit(const Spec: TSpecifier): Double; class operator Implicit(const Spec: TSpecifier): Integer; class operator Implicit(const Spec: TSpecifier): Int64; class operator Implicit(const Spec: TSpecifier): TValue; class operator Implicit(const Spec: TSpecifier): WideString; class operator Implicit(const Spec: TSpecifier): IInterface; case NativeType: Integer of varInteger: (I: Integer); varInt64: (I64: Int64); varLongWord: (C: Cardinal); varDouble: (D: Double); varObject: (O: TValue); end; My plans is to have a single framework compatible with Delphi 2007/2009 and FPC, so Ill not use some D2009 only resources, but implicit operators make the live of users very better to write less and better code. Can I have any hope about this subject? What does it prevent you from using FPC's operator overloading capabilities to do so which has FPC for 10 years? ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal freepascal search is not working, With google I found http://courses.cs.vt.edu/~cs3304/FreePascal/doc/ref/node12.html Interesting but is not what I mention, it is just the basic. -- Cesar Romero http://blogs.liws.com.br/cesar http://blogs.liws.com.br/cesar/?feed=rss2 ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Record Method and Operators
Cesar Romero schrieb: Florian Klaempfl escreveu: Cesar Romero schrieb: Hi, Im wondering if FPC Team have plans to support Record Methods/Operators in future versions of FPC I read the actual Future plans and the most closed item is RTL:: More compatibility with later Delphi versions. But it do not means that records can be changed. I want to implement my ValueTypes using record with implicit operators and constructor/destructor, like this code written by a friend, Lee Nover. TSpecifier = record S: AnsiString; WS: WideString; Intf: IInterface; class operator Implicit(const S: AnsiString): TSpecifier; class operator Implicit(const C: Cardinal): TSpecifier; class operator Implicit(const D: Double): TSpecifier; class operator Implicit(const I: Integer): TSpecifier; class operator Implicit(const I64: Int64): TSpecifier; class operator Implicit(const V: TValue): TSpecifier; class operator Implicit(const WS: WideString): TSpecifier; class operator Implicit(const Intf: IInterface): TSpecifier; class operator Implicit(const Spec: TSpecifier): AnsiString; class operator Implicit(const Spec: TSpecifier): Cardinal; class operator Implicit(const Spec: TSpecifier): Double; class operator Implicit(const Spec: TSpecifier): Integer; class operator Implicit(const Spec: TSpecifier): Int64; class operator Implicit(const Spec: TSpecifier): TValue; class operator Implicit(const Spec: TSpecifier): WideString; class operator Implicit(const Spec: TSpecifier): IInterface; case NativeType: Integer of varInteger: (I: Integer); varInt64: (I64: Int64); varLongWord: (C: Cardinal); varDouble: (D: Double); varObject: (O: TValue); end; My plans is to have a single framework compatible with Delphi 2007/2009 and FPC, so Ill not use some D2009 only resources, but implicit operators make the live of users very better to write less and better code. Can I have any hope about this subject? What does it prevent you from using FPC's operator overloading capabilities to do so which has FPC for 10 years? ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal freepascal search is not working, With google I found http://courses.cs.vt.edu/~cs3304/FreePascal/doc/ref/node12.html Interesting but is not what I mention, it is just the basic. In which regard, quoting: The assignment operator is also used to convert types from one type to another. The compiler will consider all overloaded assignment operators till it finds one that matches the types of the left hand and right hand expressions. If no such operator is found, a 'type mismatch' error is given. ? It's not our fault that CG choose another syntax. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Record Method and Operators
Florian, In which regard, quoting: The assignment operator is also used to convert types from one type to another. The compiler will consider all overloaded assignment operators till it finds one that matches the types of the left hand and right hand expressions. If no such operator is found, a 'type mismatch' error is given. ? It's not our fault that CG choose another syntax. ___ It is nobody fault, Im happy to have FPC around, and all resources is welcome. But my question was Is there any plans to support a compatible sintaxe? Yes, Maybe or No, will be a good answer. I dont want to blame FPC team or Delphi Team, I hope I can have a compatible sintaxe, and asking here I think I have more changes to get a positive answer. Thank you, -- Cesar Romero http://blogs.liws.com.br/cesar http://blogs.liws.com.br/cesar/?feed=rss2 ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Record Method and Operators
Cesar Romero schrieb: Florian, In which regard, quoting: The assignment operator is also used to convert types from one type to another. The compiler will consider all overloaded assignment operators till it finds one that matches the types of the left hand and right hand expressions. If no such operator is found, a 'type mismatch' error is given. ? It's not our fault that CG choose another syntax. ___ It is nobody fault, Im happy to have FPC around, and all resources is welcome. But my question was Is there any plans to support a compatible sintaxe? Yes, Maybe or No, will be a good answer. Unlikely to be done by the current developers, it simply duplicates functionality. I dont want to blame FPC team or Delphi Team, I hope I can have a compatible sintaxe, and asking here I think I have more changes to get a positive answer. Indeed, if someone submits a patch ;) ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
