Re: [fpc-devel] Feature announcement: Generic functions, procedures and methods
2015-11-21 17:32 UTC, Sven Barth : > Hello together! > > I'm pleased to finally announce the addition of generic functions, > procedures and methods (collectively called "routines") to Free Pascal > which allows writing type safe methods that can be used for multiple types. Congratulations ! -- Inoussa O. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] [Lazarus] FPC Pestering Peacock (3.0.0) release
Sweeet! For Linux users here is a complete FPC 3.0 release + Lazarus from svn build script: http://cache.getlazarus.org/download/linux/install-3.0.sh ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] FPC Pestering Peacock (3.0.0) release
Hello, We are happy to announce the release of the Free Pascal Compiler version 3.0.0 "Pestering Peacock". This version includes support for, a.o., several new platforms, codepage-aware strings, and an integrated Pascal source-repository (fppkg). New features are listed at http://wiki.freepascal.org/FPC_New_Features_3.0 Changes that may break backwards compatibility are documented at http://wiki.freepascal.org/User_Changes_3.0 The 3.0.0 docs is available at http://www.freepascal.org/docs-html/3.0.0/fpctoc.htm Downloads are available at our website: http://www.freepascal.org/download.var Enjoy! The Free Pascal Compiler Team Free Pascal Compiler Version 3.0.0 * Introduction Please also read the platform specific README file, if it exists. This package contains an advanced freeware 32-bit/64-bit/16-bit pascal compiler for several platforms. The language and the runtime library are almost compatible with Turbo Pascal 7.0 and recent Delphi releases. There is also partial support for the Macintosh pascal dialect. News and changes related to this release are described in whatsnew.txt. Free Pascal 3.0.0 is currently available for the following platforms: - Linux-i386 - Linux-x86_64 (amd64) - Linux-powerpc - Linux-sparc - Linux-ARM - Win32-i386 (2000/XP, WinNT or later) - Win64-x86_64 (XP or later) - Wince-ARM (cross compiled from win32-i386) - FreeBSD-i386 - FreeBSD-x86_64 - Mac OS X/Darwin for PowerPC (32 and 64 bit) - Mac OS X/Darwin for Intel (32 and 64 bit) - iOS (ARM and AArch64/ARM64) and iPhoneSimulator (32 and 64 bit) - OS/2-i386 (OS/2 Warp v3.0, 4.0, WarpServer for e-Business and eComStation) - Haiku-i386 - GO32v2-i386 - Nintendo Gameboy Advance-ARM (cross compile from win32-i386) - Nintendo DS-ARM (cross compile from win32-i386) - Nintendo Wii-powerpc (cross compile from win32-i386) - AIX 5.3 and later for PowerPC (32 and 64 bit) - Java JVM (1.5 and later) and Android Dalvik (Android 4.0 and later) - Android (ARM, i386, MIPS) via cross-compiling. - MSDos-i8086 (cross compiled from win32-i386 or Linux) - Amiga, MorphOS and AROS There are other platforms (like other BSD variants) which are more or less working, but there is currently no maintainer for them and thus we cannot provide adequate support. If you want to change this and create and maintain versions for other platforms and targets, feel free to contact us, e-mail addresses are listed below. * Features - high speed compiler - fully 16, 32 or 64-bit code - 32 bit compiler can be used on x86_64 Linux distributions to compile 32 bit applications - language features: - almost fully compatible with Borland Pascal and Borland Delphi - ansi strings - wide strings - exception support - RTTI support - procedure overloading - generics (experimental) - operator overloading - COM, CORBA and raw interfaces support - dynamic array support - variant support - inlining - code optimizer: - peephole optimizer (80x86 only) - jump optimizer - loading of variables into registers - assembler level dataflow analyzer (80x86 only) - stack frame eliminations - sophisticated register allocator - integrated BASM (built-in assembler) parser - supports ATT syntax used by GNU C - supports Intel syntax used by Turbo Pascal (x86-only) - can compile code into assembler source code for these assemblers: - GNU Assembler (GAS) - Netwide assembler (Nasm) - Microsoft Assembler/Turbo Assembler (Masm/Tasm) - Watcom assembler (wasm) - internal assembler for ultra fast object file generation - can call external C code - h2pas utility to convert .h files to Pascal units - smart linking (also known as dead code stripping) - support for the GNU debugger - integrated development environment (disabled by default on Mac OS X) - powerful user friendly Wordstar compatible multi file editor - context sensitive help supports help files in HTML, Windows HLP and Borland TPH format. - debugger on most platforms - can create binaries running natively under both DOS and OS/2 (EMX version) - no need for Linux distribution specific binaries, programs you write run on all distributions - high quality documentation * Minimum requirements Processor: i386, x86_64, PowerPC, ARM, MIPS, i8086, Motorola 68k, Sparc or JVM runtime Win32: - MS Windows NT/2000/XP or later (Win95, 98 and ME are not supported in FPC officially any longer). - 16 MB RAM OS/2: - OS/2 Warp v3.0 with one of late fixpaks - FP 3
Re: [fpc-devel] RTTI
On 2015-11-25 04:38 AM, Michael Van Canneyt wrote: One must admire the subtle announcement in this reply ;-) I know, right?? :) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] RTTI
On 25.11.2015 19:47, Michael Van Canneyt wrote: On Wed, 25 Nov 2015, Sven Barth wrote: Virtual method interceptors are not implemented, but they are planned just like every other Delphi compatible part of the RTTI. They require a bit of platform dependent support though as they'll need to deal with calling conventions (even if it might only be one as AFAIK we only allow the default calling convention for virtual methods...). Sounds like the same code as for interface method RTTI can be reused. But that will only provide half of it, because a Virtual Method Interceptor (VMI) also needs to provide the callee while for the interface method RTTI (or later on Invoke()) you only need to provide the necessary means to call the function (which a VMI needs to be able to do as well, which is what I mean "half"). Hmh. Why does it need to provide the callee ? I thought it just meant inserting a stub in the VMT and make sure all arguments are passed correctly ? No doubt you know better :) The method stub needs to call the OnBefore and OnAfter handlers before and after calling the virtual method that had been intercepted (and here it needs to know which method had been intercepted as well, because *all* virtual methods are hooked), thus it needs to preserve the original arguments across the calls to OnBefore and OnAfter (this would not be required if passed on the stack, but e.g. on i386 the register calling convention is used which stores stuff in registers). In addition it needs to pass on the parameters to the handlers and return the result. So it indeed needs to provide a full callee. Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] RTTI
On Wed, 25 Nov 2015, Sven Barth wrote: Virtual method interceptors are not implemented, but they are planned just like every other Delphi compatible part of the RTTI. They require a bit of platform dependent support though as they'll need to deal with calling conventions (even if it might only be one as AFAIK we only allow the default calling convention for virtual methods...). Sounds like the same code as for interface method RTTI can be reused. But that will only provide half of it, because a Virtual Method Interceptor (VMI) also needs to provide the callee while for the interface method RTTI (or later on Invoke()) you only need to provide the necessary means to call the function (which a VMI needs to be able to do as well, which is what I mean "half"). Hmh. Why does it need to provide the callee ? I thought it just meant inserting a stub in the VMT and make sure all arguments are passed correctly ? No doubt you know better :) Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] RTTI
On 25.11.2015 17:52, Michael Van Canneyt wrote: On Wed, 25 Nov 2015, Sven Barth wrote: Am 25.11.2015 14:58 schrieb "Michael Van Canneyt" : On Wed, 25 Nov 2015, Anthony Walter wrote: Can someone refer me to a document regarding the whats planned for FPC RTTI improvements? Is it aiming to support the current Delphi RTTI improvements (attributes, virtual method intercepts, location and tvalue) or something else? There is no document. To my knowledge: - Attributes are supported in a branch already scheduled to be merged after 3.0.0 is out. - The location and tvalue are in the branch for which the merge request was just posted. - I think virtual method intercepts are not implemented or planned. I am not sure whether this needs many extra things in the compiler, it just requires the interface RTTI and a RTL helper class ? Virtual method interceptors are not implemented, but they are planned just like every other Delphi compatible part of the RTTI. They require a bit of platform dependent support though as they'll need to deal with calling conventions (even if it might only be one as AFAIK we only allow the default calling convention for virtual methods...). Sounds like the same code as for interface method RTTI can be reused. But that will only provide half of it, because a Virtual Method Interceptor (VMI) also needs to provide the callee while for the interface method RTTI (or later on Invoke()) you only need to provide the necessary means to call the function (which a VMI needs to be able to do as well, which is what I mean "half"). Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] RTTI
On Wed, 25 Nov 2015, Sven Barth wrote: Am 25.11.2015 14:58 schrieb "Michael Van Canneyt" : On Wed, 25 Nov 2015, Anthony Walter wrote: Can someone refer me to a document regarding the whats planned for FPC RTTI improvements? Is it aiming to support the current Delphi RTTI improvements (attributes, virtual method intercepts, location and tvalue) or something else? There is no document. To my knowledge: - Attributes are supported in a branch already scheduled to be merged after 3.0.0 is out. - The location and tvalue are in the branch for which the merge request was just posted. - I think virtual method intercepts are not implemented or planned. I am not sure whether this needs many extra things in the compiler, it just requires the interface RTTI and a RTL helper class ? Virtual method interceptors are not implemented, but they are planned just like every other Delphi compatible part of the RTTI. They require a bit of platform dependent support though as they'll need to deal with calling conventions (even if it might only be one as AFAIK we only allow the default calling convention for virtual methods...). Sounds like the same code as for interface method RTTI can be reused. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] RTTI
Am 25.11.2015 14:58 schrieb "Michael Van Canneyt" : > > > > On Wed, 25 Nov 2015, Anthony Walter wrote: > >> Can someone refer me to a document regarding the whats planned for FPC RTTI >> improvements? Is it aiming to support the current Delphi RTTI improvements >> (attributes, virtual method intercepts, location and tvalue) or something >> else? > > > There is no document. > > To my knowledge: > > - Attributes are supported in a branch already scheduled to be merged after 3.0.0 is out. > > - The location and tvalue are in the branch for which the merge request was just posted. > > - I think virtual method intercepts are not implemented or planned. > I am not sure whether this needs many extra things in the compiler, it just > requires the interface RTTI and a RTL helper class ? Virtual method interceptors are not implemented, but they are planned just like every other Delphi compatible part of the RTTI. They require a bit of platform dependent support though as they'll need to deal with calling conventions (even if it might only be one as AFAIK we only allow the default calling convention for virtual methods...). Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] RTTI
2015-11-25 15:00 GMT+01:00 Michael Van Canneyt : > > There is no document. > > To my knowledge: > > - Attributes are supported in a branch already scheduled to be merged > after 3.0.0 is out. > > - The location and tvalue are in the branch for which the merge request > was just posted. > > - I think virtual method intercepts are not implemented or planned. > I am not sure whether this needs many extra things in the compiler, it > just > requires the interface RTTI and a RTL helper class ? for us, mORMot users and contributors, for now the improvements included in InterfaceRTTI branch are fine to keep engine without workarounds ( http://svn.freepascal.org/cgi-bin/viewvc.cgi/branches/interfacertti/?sortby=date&view=log ). -- Best regards, Maciej Izak ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] RTTI
On Wed, 25 Nov 2015, Anthony Walter wrote: Can someone refer me to a document regarding the whats planned for FPC RTTI improvements? Is it aiming to support the current Delphi RTTI improvements (attributes, virtual method intercepts, location and tvalue) or something else? There is no document. To my knowledge: - Attributes are supported in a branch already scheduled to be merged after 3.0.0 is out. - The location and tvalue are in the branch for which the merge request was just posted. - I think virtual method intercepts are not implemented or planned. I am not sure whether this needs many extra things in the compiler, it just requires the interface RTTI and a RTL helper class ? Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] RTTI
Can someone refer me to a document regarding the whats planned for FPC RTTI improvements? Is it aiming to support the current Delphi RTTI improvements (attributes, virtual method intercepts, location and tvalue) or something else? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] RTTI
Am 25.11.2015 09:24 schrieb "Maciej Izak" : > > 2015-11-22 12:45 GMT+01:00 Maciej Izak : >> >> 2015-11-21 12:06 GMT+01:00 Arnaud Bouchez : >>> >>> What do you think of merging the InterfaceRTTI branch with the FPC trunk? >> >> >> Indeed. Very important... Ping core team? > > > No one can help? Sven? I think it is very close to your interests? Just one word: time. Nothing more, nothing less. Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] RTTI
On Wed, 25 Nov 2015, Jonas Maebe wrote: Michael Van Canneyt wrote on Wed, 25 Nov 2015: On Wed, 25 Nov 2015, Maciej Izak wrote: 2015-11-22 12:45 GMT+01:00 Maciej Izak : 2015-11-21 12:06 GMT+01:00 Arnaud Bouchez : What do you think of merging the InterfaceRTTI branch with the FPC trunk? Indeed. Very important... Ping core team? No one can help? Sven? I think it is very close to your interests? To the best of my knowledge: The patch will not be merged to trunk, not today, not tomorrow, because the mechanism is not generic and highly processor specific. I'll have a look at how to make it generic once the llvm backend works for Darwin/x86_64 (which should be soon). One must admire the subtle announcement in this reply ;-) Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] RTTI
Michael Van Canneyt wrote on Wed, 25 Nov 2015: On Wed, 25 Nov 2015, Maciej Izak wrote: 2015-11-22 12:45 GMT+01:00 Maciej Izak : 2015-11-21 12:06 GMT+01:00 Arnaud Bouchez : What do you think of merging the InterfaceRTTI branch with the FPC trunk? Indeed. Very important... Ping core team? No one can help? Sven? I think it is very close to your interests? To the best of my knowledge: The patch will not be merged to trunk, not today, not tomorrow, because the mechanism is not generic and highly processor specific. I'll have a look at how to make it generic once the llvm backend works for Darwin/x86_64 (which should be soon). Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] RTTI
On Wed, 25 Nov 2015, Maciej Izak wrote: 2015-11-22 12:45 GMT+01:00 Maciej Izak : 2015-11-21 12:06 GMT+01:00 Arnaud Bouchez : What do you think of merging the InterfaceRTTI branch with the FPC trunk? Indeed. Very important... Ping core team? No one can help? Sven? I think it is very close to your interests? To the best of my knowledge: The patch will not be merged to trunk, not today, not tomorrow, because the mechanism is not generic and highly processor specific. As long as there is no mechanism that is known to work on all supported CPUs, this will not be merged. We are making a cross-platform compiler. So it is of paramount importance that new features work on ALL cpus, not just the most-used ones. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] RTTI
2015-11-22 12:45 GMT+01:00 Maciej Izak : > 2015-11-21 12:06 GMT+01:00 Arnaud Bouchez : > >> What do you think of merging the InterfaceRTTI branch with the FPC trunk? >> > > Indeed. Very important... Ping core team? > No one can help? Sven? I think it is very close to your interests? -- Best regards, Maciej Izak ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
