Re: [fpc-devel] RTTI unit
Am 29.08.2010 22:48, schrieb Graeme Geldenhuys: On 29 August 2010 15:32, Dimitri Smits wrote: You're free to choose one over the other; Personally, I favour fpc-unit style. I find it works most easily, definitely if you use Lazarus. so, lpi files and the like are acceptable in fpc? I think he means that there is a GUI unit test runner for fpcunit included with Lazarus (and fpGUI by the way). As for the .lpi files, I don't think those belong in the FPC project source. FPC and Lazarus are separate projects, not everybody using FPC use Lazarus. After all, all IDE's worth using, should have a feature to create a IDE Project File from a program unit. I know Lazarus IDE and MSEide can do this - so that again indicates that a specific IDE project file doesn't need to be in the FPC source code. LPI files are already included with FPC. E.g. for the compiler itself (so you don't need to add all search paths manually...) and for the Win32 RTL (excluding the system unit). No autogenerate system will add the correct searchpaths by itself, so some file must be included for that system. So why not use the LPI file... Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] RTTI unit
Op 2010-08-30 09:45, Sven Barth het geskryf: LPI files are already included with FPC. E.g. for the compiler itself (so you don't need to add all search paths manually...) and for the Win32 RTL (excluding the system unit). FPC has support for external config files which could handle this for you. In the fpGUI project I have many such config files called extrafpc.cfg. Each line of that config file is a compiler parameter, you can use IFDEF functionality and even FPC's macros. See the example below. This is a more advanced example than usual, but it shows IFDEF usage and FPC macros like $fpctarget. To use this from the command line: fpc -dX11 @extrafpc.cfg program_unit.pas - #* * * I M P O R T A N T * * * # You need to specify which backend you are compiling for. This # will be the only extra compiler parameter you use. # # Your options are: # -dX11 for X11 support (eg: Linux or FreeBSD) # -dGDI for Windows GDI support # -dCarbon for Mac OS X Carbon support. # Slashes are also allowed under Dos or Windows # search path for include files -Fi. -Ficorelib #IFDEF X11 -Ficorelib/x11/ #ENDIF #IFDEF GDI -Ficorelib/gdi/ #ENDIF # searchpath for units and other system dependent things -Fu. -Fucorelib/ #IFDEF X11 #WRITE Compiling X11 CoreLib -Fucorelib/x11/ #ENDIF #IFDEF GDI #WRITE Compiling GDI CoreLib -Fucorelib/gdi/ #ENDIF #IFDEF Carbon #WRITE Compiling Carbon CoreLib -Fucorelib/carbon/ #ENDIF -Fugui/ -Fugui/db/ # Unit output path -FU../lib/$fpctarget/ - So again, no need to include some IDE specific files, not related to the FPC project or sources. Otherwise we can start adding FP (text) IDE, MSEide, fpGUI IDE, Syn Editor project files etc Where does it end? In addition to such external config files, FPC also includes the fpcmake.pas functionality. This again allows it to setup search paths etc. for a project, even the compiler itself. BTW: Lazarus IDE can read such external config files too, so again it is very easy to setup a Lazarus project using a program unit, and simply telling it to read the extrafpc.cfg file for search path information. With MSEide you can do the same. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net/fpgui/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] RTTI unit
Am 30.08.2010 10:15, schrieb Graeme Geldenhuys: Op 2010-08-30 09:45, Sven Barth het geskryf: LPI files are already included with FPC. E.g. for the compiler itself (so you don't need to add all search paths manually...) and for the Win32 RTL (excluding the system unit). FPC has support for external config files which could handle this for you. In the fpGUI project I have many such config files called extrafpc.cfg. Each line of that config file is a compiler parameter, you can use IFDEF functionality and even FPC's macros. See the example below. [...] In addition to such external config files, FPC also includes the fpcmake.pas functionality. This again allows it to setup search paths etc. for a project, even the compiler itself. BTW: Lazarus IDE can read such external config files too, so again it is very easy to setup a Lazarus project using a program unit, and simply telling it to read the extrafpc.cfg file for search path information. With MSEide you can do the same. I'll find a reason to include *.lpi files... I'll find one... I'll find one... damn... I failed :P It might be practical to extend Lazarus (and maybe the other IDEs as well) to auto search for an extrafpc.cfg in the same dir as the program file so that it is used automatically. Does identifier search/completion work in Lazarus if you use a extrafpc.cfg to define search paths? Another possibility would be to extend fpcmake to generate different IDE project files besides the Makefile as well. Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] RTTI unit
On Mon, 30 Aug 2010, Sven Barth wrote: Am 30.08.2010 10:15, schrieb Graeme Geldenhuys: Op 2010-08-30 09:45, Sven Barth het geskryf: LPI files are already included with FPC. E.g. for the compiler itself (so you don't need to add all search paths manually...) and for the Win32 RTL (excluding the system unit). FPC has support for external config files which could handle this for you. In the fpGUI project I have many such config files called extrafpc.cfg. Each line of that config file is a compiler parameter, you can use IFDEF functionality and even FPC's macros. See the example below. [...] In addition to such external config files, FPC also includes the fpcmake.pas functionality. This again allows it to setup search paths etc. for a project, even the compiler itself. BTW: Lazarus IDE can read such external config files too, so again it is very easy to setup a Lazarus project using a program unit, and simply telling it to read the extrafpc.cfg file for search path information. With MSEide you can do the same. I'll find a reason to include *.lpi files... I'll find one... I'll find one... damn... I failed :P It might be practical to extend Lazarus (and maybe the other IDEs as well) to auto search for an extrafpc.cfg in the same dir as the program file so that it is used automatically. That presupposes that the use of extrafpc.cfg is a common thing. It is not, this is something that Graeme uses. Does identifier search/completion work in Lazarus if you use a extrafpc.cfg to define search paths? Another possibility would be to extend fpcmake to generate different IDE project files besides the Makefile as well. fpcmake will be phased out, it's a bad idea to extend it. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] RTTI unit
Am 30.08.2010 11:23, schrieb Michael Van Canneyt: It might be practical to extend Lazarus (and maybe the other IDEs as well) to auto search for an extrafpc.cfg in the same dir as the program file so that it is used automatically. That presupposes that the use of extrafpc.cfg is a common thing. It is not, this is something that Graeme uses. But it's a format that is understood by the compiler and does not rely on an external IDE. May be it should be made common instead of IDE specific project files. Don't get me wrong here: I am not against the usage of LPI files in the FPC sources (because I'm using Lazarus), but Graeme raised a valid point: not everyone uses Lazarus and thus we might think about using a file format that can be used by more IDEs than just Lazarus. The config file might be such a format, but it depends on the support by the involved IDEs (FP IDE, Lazarus, MSEide). Does identifier search/completion work in Lazarus if you use a extrafpc.cfg to define search paths? Another possibility would be to extend fpcmake to generate different IDE project files besides the Makefile as well. fpcmake will be phased out, it's a bad idea to extend it. Right you are. What about fppkg then? Would it be a feasible idea or a valid task to let it create project files for different IDEs? Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] RTTI unit
Op 2010-08-30 10:43, Sven Barth het geskryf: It might be practical to extend Lazarus (and maybe the other IDEs as well) to auto search for an extrafpc.cfg in the same dir as the program file so that it is used automatically. I think I can speak for a few developers, that such automations can just cause more frustration than good. I personally hate software that tries to be too clever. Lazarus IDE is already on the borderline of that. Does identifier search/completion work in Lazarus if you use a extrafpc.cfg to define search paths? I think it does. Either way, when it comes to FPC sources, Lazarus IDE has a config option that you use to tell it where FPC sources are located, so it already parsed cached that information for auto-completion and code navigation. Another possibility would be to extend fpcmake to generate different IDE project files besides the Makefile as well. I don't think this is viable: * There are just too many programmer editors or IDE's that could be used, so this will be a never ending job. * fpcmake is apparently being phased out - although a oil tanker moves faster that that. :) NOTE: A correction to my previous message. I meant to type fpmake and _not_ fpcmake. fpmake is apparently the replacement to fpcmake. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net/fpgui/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] RTTI unit
Op 2010-08-30 11:23, Michael Van Canneyt het geskryf: That presupposes that the use of extrafpc.cfg is a common thing. It is not, this is something that Graeme uses. FPC has had support for such extra config files since I started using FPC (+-5 years ago). It's also a documented feature, so it's not like I'm using some corner case hack - it's a legit feature of FPC, and a very handy one. Secondly, Lazarus IDE has also had support for reading such extra config files since I started using Lazarus (also 5+ years ago). This FPC feature has been in existence for a very long time. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net/fpgui/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] RTTI unit
On Mon, 30 Aug 2010, Graeme Geldenhuys wrote: Op 2010-08-30 11:23, Michael Van Canneyt het geskryf: That presupposes that the use of extrafpc.cfg is a common thing. It is not, this is something that Graeme uses. FPC has had support for such extra config files since I started using FPC (+-5 years ago). It's also a documented feature, so it's not like I'm using some corner case hack - it's a legit feature of FPC, and a very handy one. Secondly, Lazarus IDE has also had support for reading such extra config files since I started using Lazarus (also 5+ years ago). This FPC feature has been in existence for a very long time. I know that, but that is not what I meant. What I meant is that you use the config file feature consistently in the same way, whereas other people don't. Therefor, basing a feature on the way you work is no better than including a .lpi file (which happens to be the way I work). What is more, the cfg file does not contain any project information: what files are part of the project. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] RTTI unit
Op 2010-08-30 11:53, Sven Barth het geskryf: file might be such a format, but it depends on the support by the involved IDEs (FP IDE, Lazarus, MSEide). As far as I know, all IDE's and programmer editors have some option to pass settings directly to the compiler as a parameter. Simply typing in @extrafpc.cfg should do the trick in all cases. ps: extrafpc.cfg is not a hard-coded file name, you can use any file name. For example, in Lazarus IDE, I use different .cfg file for various build modes (eg: debug build, release build, verbose loggging etc.) No need to fiddle with compiler setting is various dialogs and tabs, simply toggle between the .cfg files. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net/fpgui/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] RTTI unit
On Mon, 30 Aug 2010, Sven Barth wrote: Am 30.08.2010 11:23, schrieb Michael Van Canneyt: It might be practical to extend Lazarus (and maybe the other IDEs as well) to auto search for an extrafpc.cfg in the same dir as the program file so that it is used automatically. That presupposes that the use of extrafpc.cfg is a common thing. It is not, this is something that Graeme uses. But it's a format that is understood by the compiler and does not rely on an external IDE. May be it should be made common instead of IDE specific project files. Don't get me wrong here: I am not against the usage of LPI files in the FPC sources (because I'm using Lazarus), but Graeme raised a valid point: not everyone uses Lazarus and thus we might think about using a file format that can be used by more IDEs than just Lazarus. The config file might be such a format, but it depends on the support by the involved IDEs (FP IDE, Lazarus, MSEide). It is IMHO not suitable, because it does not contain information on the actual project files. It's just suitable to guide compilation. Does identifier search/completion work in Lazarus if you use a extrafpc.cfg to define search paths? Another possibility would be to extend fpcmake to generate different IDE project files besides the Makefile as well. fpcmake will be phased out, it's a bad idea to extend it. Right you are. What about fppkg then? Would it be a feasible idea or a valid task to let it create project files for different IDEs? Definitely not, that would be the opposite of what we try to achieve: get fppkg support into the IDEs. So in fact the solution is simple; provide a fpmake.pp file, and let the IDE's figure it out from there. We'll take that as a rule for contributions from now on :) I'll discuss this in the FPC core list. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] RTTI unit
Op 2010-08-30 12:04, Michael Van Canneyt het geskryf: same way, whereas other people don't. Therefor, basing a feature on the way you work is no better than including a .lpi file (which happens to be the way I work). I got introduced to that feature years ago in the mailing list. So it's not just me that uses it that way. Even the standard fpc.cfg generated by FPC uses IFDEF and macros - similar to what I do. So I don't agree that it's as special feature only Graeme uses. An least in a pinch, one can compile a new compiler or RTL from the command line with ease. Have various config files to enable/disable debugging, line info etc. Very handy for compiler or RTL or FCL development. Currently Lazarus doesn't have various build modes, but the config files do allow for that. What is more, the cfg file does not contain any project information: what files are part of the project. Neither does many of the .lpi files included in FPC sources. :) Most of them only contain the main program unit and maybe one or two other units [see compiler directory]. fpdoc.lpi being the exception. ;-) Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net/fpgui/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] RTTI unit
Am 30.08.2010 11:58, schrieb Graeme Geldenhuys: Does identifier search/completion work in Lazarus if you use a extrafpc.cfg to define search paths? I think it does. Either way, when it comes to FPC sources, Lazarus IDE has a config option that you use to tell it where FPC sources are located, so it already parsed cached that information for auto-completion and code navigation. No, that is not working that way. I set my FPC source directory to the sources of the latest release, but I'm playing around with the trunk compiler (read as: building the compiler from the IDE). So I need the search paths of the compiler subdirectories and I don't want to add them manually if some file in the compiler dir already contains them. Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] RTTI unit
Op 2010-08-30 12:16, Sven Barth het geskryf: No, that is not working that way. I set my FPC source directory to the sources of the latest release, but I'm playing around with the trunk Then file a Lazarus IDE bug report. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net/fpgui/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] RTTI unit
On Mon, 30 Aug 2010, Graeme Geldenhuys wrote: Op 2010-08-30 12:04, Michael Van Canneyt het geskryf: same way, whereas other people don't. Therefor, basing a feature on the way you work is no better than including a .lpi file (which happens to be the way I work). I got introduced to that feature years ago in the mailing list. So it's not just me that uses it that way. Even the standard fpc.cfg generated by FPC uses IFDEF and macros - similar to what I do. So I don't agree that it's as special feature only Graeme uses. As far as I can see, most people just use the fpc provided config file, no extra files like you do. An least in a pinch, one can compile a new compiler or RTL from the command line with ease. Have various config files to enable/disable debugging, line info etc. Very handy for compiler or RTL or FCL development. Currently Lazarus doesn't have various build modes, but the config files do allow for that. Totally correct, and I don't dispute that. What is more, the cfg file does not contain any project information: what files are part of the project. Neither does many of the .lpi files included in FPC sources. :) Most of them only contain the main program unit and maybe one or two other units [see compiler directory]. fpdoc.lpi being the exception. ;-) In short, we can drop the matter. People can submit whatever they like; the FPC team member will decide what gets commited and what not. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] RTTI unit
Am 30.08.2010 12:22, schrieb Graeme Geldenhuys: Op 2010-08-30 12:16, Sven Barth het geskryf: No, that is not working that way. I set my FPC source directory to the sources of the latest release, but I'm playing around with the trunk Then file a Lazarus IDE bug report. Heh? I think you misunderstood me here. I'm setting the FPC source directory to the 2.4.0 sources, because that's the main compiler I'm using. When I work with in the trunk compiler I compile it inside the IDE using the 2.4.0 RTL. And the search paths of the compilers LPI file are pointing to the relative subdirectories of the compiler. So what I'm trying to tell you here is this: I can't use Lazarus' FPC source cache, because that are different units (trunk vs. 2.4.0). Also I think that Lazarus parses only RTL and Packages units and not the compiler ones. Is it more clear now? Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] RTTI unit
Op 2010-08-30 13:32, Sven Barth het geskryf: Is it more clear now? I understand that, but you still will have to take it up with the Lazarus developers. eg: if you want to navigate the compiler project (like you would do with any other of your projects), and you are using a extrafpc.cfg file, I gather you would like Lazarus IDE to read out the path information inside the extrafpc.cfg file (if they exist), and add those to the search path cached in Lazarus IDE - so you can do code navigation (ctrl+left_click on units or types) without specifying search paths in the Project Compiler Options Paths dialog. I understood that you tried code navigation and Lazarus couldn't find code specified in the paths inside the extrafpc.cfg file. If this is indeed the case, then report a bug or feature request, so Lazarus could read search paths from the extrafpc.cfg file. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net/fpgui/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] RTTI unit
Am 30.08.2010 14:25, schrieb Graeme Geldenhuys: I understood that you tried code navigation and Lazarus couldn't find code specified in the paths inside the extrafpc.cfg file. If this is indeed the case, then report a bug or feature request, so Lazarus could read search paths from the extrafpc.cfg file. The point is that I didn't tried it. I asked you (and the rest of the list) whether this works, so that using and including a extra config file would be useful in the IDE as well. You interpreted to much into my mails :P Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] RTTI unit
29.08.2010 3:46, Dimitri Smits wrote: What I want to do: Since Delphi 2010, there is a new unit in the RTL that makes RTTI more of a breeze. I'd like to port (meaning: compatible interface, fpc implementation) this unit to fpc-rtl. Initially port over what is there already. Later maybe include in the compiler stuff like scoped RTTI (not just published alone) and customattributes if there is need for that level of compatibility. Also, adding more methods on the current interface is possible too. It is more than just a readable substitute for TypInfo. At the present state of fpc compiler it is technically imposible to port delphi rtti unit. To do this you need first to implement the next compiler features: 1. Extended records (methods, class operators) 2. Generics as in delphi 3. Attributes Once I tried to implement extended records in the compiler but the changes were too big for the time I had and I had left that idea for the better time. Best regards, Paul Ishenin. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] RTTI unit
Michael, thank you for the reply. It makes a few things a lot clearer for me. I'll comment a bit more below. - Michael Van Canneyt mich...@freepascal.org schreef: On Sat, 28 Aug 2010, Dimitri Smits wrote: What I want to do: Since Delphi 2010, there is a new unit in the RTL that makes RTTI more of a breeze. I'd like to port (meaning: compatible interface, fpc implementation) this unit to fpc-rtl. Initially port over what is there already. Later maybe include in the compiler stuff like scoped RTTI (not just published alone) and customattributes if there is need for that level of compatibility. Also, adding more methods on the current interface is possible too. It is more than just a readable substitute for TypInfo. Well, the compiler doesn't support custom attributes. I know, neither does it support RTTI-scoping (only published members of a class, and other types are 'public') or run-time unit per package registration or ... Like I said: first implement what is there and can be ported to fpc. That way I do not have to dive into compiler-output and parsing (for now). Later on, it can be expanded with those features that DO get implemented or not if they'll never be. After initial porting, I might extend the interfaces with a few methods (e.g.: getters+setters with AsString+AsInteger+As... etc). But first: port what is there. For this I'd like to know a few things: - First off: would this kind of thing even be considered for inclusion? Yes. Any unit to increase Delphi compatibility is worth of inclusion. good to know. to be placed next to types unit in objpas, I presume. - How to get it into repository/feedback from core? (through feature request with attachment in mantis?) I'll handle that; Just post it on mantis, I'll look into it. attach the unit, or in patch form? - Codestyle conventions for fpc-code? (including licence-header etc) Modified LGPL header (see any rtl file). Code style: follow the Borland style guide. that header, with your name Florian or mine or 3? :-) - Is there (besides System, SysUtils, Types and the Variant-units) another place to look for RTTI-types? Not sure I know what you mean by this ? Is there another unit other than those that contains structures defs mapping to what the compiler generates? (like ptypeinfo, but also for punittype, or packages) anything I've missed regarding lowlevel info on types language constructs - Where do I need to take care off (how to include it in rtl package, ..., unit-dependencies )? Nothing. I'll take care of that, you just write the code. what i meant was: don't use generic types like fpglist and/or consorts that are not in the rtl package. (what files can I check to see what is included in the rtl so I don't accidentally make cyclic dependencies. - I've read somewhere that nothing gets included if no unit-tests are - provided. Is this using fpcunit? Any pointers on the testingsystem, - do's and don'ts are welcome. You can use fpcunit; there are sample tests in the fcl-fpcunit directory. to be placed under what dir? fpcunit would have been my choice nevertheless. :-) All other daily test programs use a different mechanism: they must return a zero exit code. Nonzero exit code means that there is an error. You're free to choose one over the other; Personally, I favour fpc-unit style. I find it works most easily, definitely if you use Lazarus. so, lpi files and the like are acceptable in fpc? Since I work on win32 (only), I'm not that familiar with makefiles. So, if I need to add anything to makefiles or copy+edit another makefile, please redirect me to more information. (mainly for testing-app, I guess) Let me handle that. Focus on the code. will do. Have to start, and probably will go through a few iterations before I post it in mantis (also, when time permits). And even then it might be something to discuss first and take a few posts to get it feature complete. if that's allright by you ;-) kind regards, Dimitri Smits ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] RTTI unit
Hi Paul, thanks for the input. - Paul Ishenin webpi...@mail.ru schreef: 29.08.2010 3:46, Dimitri Smits wrote: What I want to do: Since Delphi 2010, there is a new unit in the RTL that makes RTTI more of a breeze. I'd like to port (meaning: compatible interface, fpc implementation) this unit to fpc-rtl. Initially port over what is there already. Later maybe include in the compiler stuff like scoped RTTI (not just published alone) and customattributes if there is need for that level of compatibility. Also, adding more methods on the current interface is possible too. It is more than just a readable substitute for TypInfo. At the present state of fpc compiler it is technically imposible to port delphi rtti unit. To do this you need first to implement the next compiler features: 1. Extended records (methods, class operators) 2. Generics as in delphi 3. Attributes 4. scopeable RTTI ($RTTI directive) Once I tried to implement extended records in the compiler but the changes were too big for the time I had and I had left that idea for the better time. incremental changes. First try the basic types, then classes/objects/records. And leave out those types for now that cannot be ported. In a next phase, then include what is needed either in compiler or fpc-specific rtti objects (in same style/spirit). As for that (4) above. The last few months I've seen this requested a few times (either direct or indirect) on mailinglists. kind regards, Dimitri Smits ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] RTTI unit
Michael Van Canneyt schrieb: For this I'd like to know a few things: - First off: would this kind of thing even be considered for inclusion? Yes. Any unit to increase Delphi compatibility is worth of inclusion. IMO compatibility with the Delphi Unicode version were a different project, requiring some manpower. There exist some more questionable features, resulting from the (attempted and dropped) .NET version, like dotted unit names. IMO we should wait for Delphi X, and then update FPC/Lazarus according to that platform independent version. DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] RTTI unit
On Sun, 29 Aug 2010, Hans-Peter Diettrich wrote: Michael Van Canneyt schrieb: For this I'd like to know a few things: - First off: would this kind of thing even be considered for inclusion? Yes. Any unit to increase Delphi compatibility is worth of inclusion. IMO compatibility with the Delphi Unicode version were a different project, requiring some manpower. There exist some more questionable features, resulting from the (attempted and dropped) .NET version, like dotted unit names. IMO we should wait for Delphi X, and then update FPC/Lazarus according to that platform independent version. There is nothing in Delphi X (due in 3 days) that will not build on these existing things. We need those first. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] RTTI unit
In our previous episode, Hans-Peter Diettrich said: For this I'd like to know a few things: - First off: would this kind of thing even be considered for inclusion? Yes. Any unit to increase Delphi compatibility is worth of inclusion. IMO compatibility with the Delphi Unicode version were a different project, requiring some manpower. There exist some more questionable features, resulting from the (attempted and dropped) .NET version, like dotted unit names. IMO we should wait for Delphi X, and then update FPC/Lazarus according to that platform independent version. Since this feature is not fully connected to unicode I don't see the need for that restriction. Even if we only allow it in a possible future D2009+ mode, changing mode assignments is probably much less work than implementing it. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] RTTI unit
In our previous episode, Michael Van Canneyt said: IMO compatibility with the Delphi Unicode version were a different project, requiring some manpower. There exist some more questionable features, resulting from the (attempted and dropped) .NET version, like dotted unit names. IMO we should wait for Delphi X, and then update FPC/Lazarus according to that platform independent version. There is nothing in Delphi X (due in 3 days) that will not build on these existing things. We need those first. Delphi Xe is not the multiplatform version anyways. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] RTTI unit
On Sun, 29 Aug 2010, Dimitri Smits wrote: Michael, thank you for the reply. It makes a few things a lot clearer for me. I'll comment a bit more below. For this I'd like to know a few things: - First off: would this kind of thing even be considered for inclusion? Yes. Any unit to increase Delphi compatibility is worth of inclusion. good to know. to be placed next to types unit in objpas, I presume. Yes. - How to get it into repository/feedback from core? (through feature request with attachment in mantis?) I'll handle that; Just post it on mantis, I'll look into it. attach the unit, or in patch form? Attach the unit to your mantis bug report. - Codestyle conventions for fpc-code? (including licence-header etc) Modified LGPL header (see any rtl file). Code style: follow the Borland style guide. that header, with your name Florian or mine or 3? :-) Just put FPC team or so. - Is there (besides System, SysUtils, Types and the Variant-units) another place to look for RTTI-types? Not sure I know what you mean by this ? Is there another unit other than those that contains structures defs mapping to what the compiler generates? (like ptypeinfo, but also for punittype, or packages) anything I've missed regarding lowlevel info on types language constructs There is nothing; the typeinfo unit contains most info apart from the compiler sources. - Where do I need to take care off (how to include it in rtl package, ..., unit-dependencies )? Nothing. I'll take care of that, you just write the code. what i meant was: don't use generic types like fpglist and/or consorts that are not in the rtl package. (what files can I check to see what is included in the rtl so I don't accidentally make cyclic dependencies. No generics, please. Generics are highly beta. Apart from that, I don't think there are any caveats. - I've read somewhere that nothing gets included if no unit-tests are - provided. Is this using fpcunit? Any pointers on the testingsystem, - do's and don'ts are welcome. You can use fpcunit; there are sample tests in the fcl-fpcunit directory. to be placed under what dir? fpcunit would have been my choice nevertheless. :-) We'll see. All other daily test programs use a different mechanism: they must return a zero exit code. Nonzero exit code means that there is an error. You're free to choose one over the other; Personally, I favour fpc-unit style. I find it works most easily, definitely if you use Lazarus. so, lpi files and the like are acceptable in fpc? Insofar as they contain only non-visual code. No dependency on the LCL. The .lpi file should just enumerate the dependencies of your pogram; session info should be in a separate file, which is not committed to SVN. Since I work on win32 (only), I'm not that familiar with makefiles. So, if I need to add anything to makefiles or copy+edit another makefile, please redirect me to more information. (mainly for testing-app, I guess) Let me handle that. Focus on the code. will do. Have to start, and probably will go through a few iterations before I post it in mantis (also, when time permits). And even then it might be something to discuss first and take a few posts to get it feature complete. if that's allright by you ;-) Of course. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] RTTI unit
In our previous episode, Michael Van Canneyt said: There is nothing in Delphi X (due in 3 days) that will not build on these existing things. We need those first. Delphi Xe is not the multiplatform version anyways. From what I've heard, the Mac version is unlikely to appear soon, if at all. Let alone a linux version. Professionally I'm not terribly interested in either atm. I am mildly interested in Windows 64-bit, but in my current job it has no real big priority either. On the other hand, when most camera manufacturers start moving focus from 32-bit to 64-bit, it needs to be there instantly. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] RTTI unit
On Sun, 29 Aug 2010, Marco van de Voort wrote: In our previous episode, Michael Van Canneyt said: There is nothing in Delphi X (due in 3 days) that will not build on these existing things. We need those first. Delphi Xe is not the multiplatform version anyways. From what I've heard, the Mac version is unlikely to appear soon, if at all. Let alone a linux version. Professionally I'm not terribly interested in either atm. I am mildly interested in Windows 64-bit, but in my current job it has no real big priority either. On the other hand, when most camera manufacturers start moving focus from 32-bit to 64-bit, it needs to be there instantly. The 64-bit version is where the focus is. Since that requires them to rework the compiler and then the complete VCL, they're in for some work. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] RTTI unit
29.08.2010 21:39, Dimitri Smits wrote: At the present state of fpc compiler it is technically imposible to port delphi rtti unit. To do this you need first to implement the next compiler features: 1. Extended records (methods, class operators) 2. Generics as in delphi 3. Attributes 4. scopeable RTTI ($RTTI directive) I mean that for implementing RTTI unit compatible by interface with delphi you need that 3 features I wrote about. Or how you will port for example TValue record: TValue = record private function GetIsEmpty: Boolean; ... procedure GetT(out Result: T); public // Easy in class operator Implicit(const Value: string): TValue; ... 1. GetIsEmpty - a method in a record. 2. GetT(out Result: T) - generics as in delphi 3. class operator Implicit(const Value: string): TValue - delphi class operators I was wrong about Attributes - seems they are not used in the rtti unit interface. Best regards, Paul Ishenin. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] RTTI unit
Op Sun, 29 Aug 2010, schreef Paul Ishenin: 29.08.2010 21:39, Dimitri Smits wrote: At the present state of fpc compiler it is technically imposible to port delphi rtti unit. To do this you need first to implement the next compiler features: 1. Extended records (methods, class operators) 2. Generics as in delphi 3. Attributes 4. scopeable RTTI ($RTTI directive) I mean that for implementing RTTI unit compatible by interface with delphi you need that 3 features I wrote about. Or how you will port for example TValue record: You can come a long way by using FPC alternatives: Use objects, and overload the := operator. Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] RTTI unit
- Michael Van Canneyt mich...@freepascal.org schreef: On Sun, 29 Aug 2010, Marco van de Voort wrote: In our previous episode, Michael Van Canneyt said: There is nothing in Delphi X (due in 3 days) that will not build on these existing things. We need those first. Delphi Xe is not the multiplatform version anyways. From what I've heard, the Mac version is unlikely to appear soon, if at all. Let alone a linux version. I have browsed through the system.pas file of 2010 on one occasion (when I had the chance). Was full of MACOS and Linux IFDEF's already! kind regards, Dimitri Smits ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] RTTI unit
On 29 August 2010 15:32, Dimitri Smits wrote: You're free to choose one over the other; Personally, I favour fpc-unit style. I find it works most easily, definitely if you use Lazarus. so, lpi files and the like are acceptable in fpc? I think he means that there is a GUI unit test runner for fpcunit included with Lazarus (and fpGUI by the way). As for the .lpi files, I don't think those belong in the FPC project source. FPC and Lazarus are separate projects, not everybody using FPC use Lazarus. After all, all IDE's worth using, should have a feature to create a IDE Project File from a program unit. I know Lazarus IDE and MSEide can do this - so that again indicates that a specific IDE project file doesn't need to be in the FPC source code. -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] RTTI unit
On Sun, 29 Aug 2010, Dimitri Smits wrote: - Michael Van Canneyt mich...@freepascal.org schreef: On Sun, 29 Aug 2010, Marco van de Voort wrote: In our previous episode, Michael Van Canneyt said: There is nothing in Delphi X (due in 3 days) that will not build on these existing things. We need those first. Delphi Xe is not the multiplatform version anyways. From what I've heard, the Mac version is unlikely to appear soon, if at all. Let alone a linux version. I have browsed through the system.pas file of 2010 on one occasion (when I had the chance). Was full of MACOS and Linux IFDEF's already! The linux ifdefs are there since 2002. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] RTTI unit
Hi, I was wondering if anybody could direct me in the right direction (either mail, wiki) with regard to following questions. What I want to do: Since Delphi 2010, there is a new unit in the RTL that makes RTTI more of a breeze. I'd like to port (meaning: compatible interface, fpc implementation) this unit to fpc-rtl. Initially port over what is there already. Later maybe include in the compiler stuff like scoped RTTI (not just published alone) and customattributes if there is need for that level of compatibility. Also, adding more methods on the current interface is possible too. It is more than just a readable substitute for TypInfo. For this I'd like to know a few things: - First off: would this kind of thing even be considered for inclusion? - How to get it into repository/feedback from core? (through feature request with attachment in mantis?) - Codestyle conventions for fpc-code? (including licence-header etc) - Is there (besides System, SysUtils, Types and the Variant-units) another place to look for RTTI-types? - Where do I need to take care off (how to include it in rtl package, ..., unit-dependencies )? - I've read somewhere that nothing gets included if no unit-tests are provided. Is this using fpcunit? Any pointers on the testingsystem, do's and don'ts are welcome. Since I work on win32 (only), I'm not that familiar with makefiles. So, if I need to add anything to makefiles or copy+edit another makefile, please redirect me to more information. (mainly for testing-app, I guess) Anyhow, the first question is the more crucial one. If anybody is interested in the (public) interfaces of the tobjecttypes, I can provide those. If there needs to be a debate first, fine by me ;-) kind regards, Dimitri Smits ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
