Re: [fpc-devel] property syntax extension
Hello, fpc-developer list. As Events (i.e callbacks at the time being) are syntactically done as properties, could it be possible that property attributes on the long run could help implementing thread Events (i.e. a class fires an event not as a callback (usually using a the main thread, but if programmed like that using a thread it defines) but uses a thread the program that sets the handler property defines ? Here the programmer does not need to write code that passes the parameters to the thread: the RTL does all this dirty stuff, helping less advanced programmers to do threaded applications like it's usually done with ADA.) -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] property syntax extension
Michael Schnell wrote: programmed like that using a thread it defines) but uses a thread the program that sets the handler property defines ? Here the programmer does not need to write code that passes the parameters to the thread: the RTL does all this dirty stuff, helping less advanced programmers to do threaded applications like it's usually done with ADA.) Are you sure this would make things easier? Code in the handler needs to be thread safe. Starting a thread is very easy, with TThread? Or do you mean you want something like work queues? Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] property syntax extension
Are you sure this would make things easier? Code in the handler needs to be thread safe. Starting a thread is very easy, with TThread? If you use common resources of course you do need to take create to do it in a thread save way. But if you want to off-load some kind of work to one or more threads you need to do the communication - especially notifications between the threads - in a way everybody needs to invent for himself. Mostly you will (or even need to) use non-portable methods (Windows-Messages) for that. I always feel that it's not nice that when doing a thread you can't use event-driven programming (as everybody does in the main thread), but need to do your own work-loop per thread. (I do know that modifying this would be a _major_ RTL enhancement. So I'm not suggesting to start working on that right here. I'm just thinking about a means to integrate it into the language at a future point in time.) Some predefined, portable and easy to understand (i.e. very similar to main-thread programing) way to work with threads would be a nice enhancement over what any other Delphi-Language successor provides right now. Here I can imagine extending Events (including may those of the standard libraries provide) to working as threads could be a way to go. Or do you mean you want something like work queues? Supposedly some queuing mechanism needs to be used to provide parameters to the thread and to pass results back to the program that defined the event would be used. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] property syntax extension
Op Sun, 21 Oct 2007, schreef Michael Van Canneyt: .ppu file format is something so general and commonly used by (Free) Pascal programmers that it should become part of our RTL. And another: A lazarus built with fpc 2.0.4 should be able to read the ppu of 2.3.x. Even though the ppu format is very stable, it is not carved in stone. It's built so that a newer version can always read an older PPU file and vice versa: an old ppu unit can read a newer file, but just doesn't know how to interpret certain blocks. This is not true. Take for example: procedure tarraydef.ppuwrite(ppufile:tcompilerppufile); begin inherited ppuwrite(ppufile); ppufile.putderef(_elementdefderef); ppufile.putderef(rangedefderef); ppufile.putaint(lowrange); ppufile.putaint(highrange); ppufile.putsmallset(arrayoptions); ppufile.writeentry(ibarraydef); end; If the arrayoptions for example becomes a large set (32 elements), an old version that will try to read a new version will read too little data. We will of course bump the ppu version, so the compile refuses old ppus. Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] property syntax extension
Op Sun, 21 Oct 2007, schreef Mattias Gaertner: Coming back to the real problem: Searching and reading the ppu is as expensive as reading the sources or reading the fpdoc xml files. So, there is no need to put the property information into the ppu - except for closed sources. ppu's are supposed to be magnitudes faster as you don't need to do any parsing. Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] property syntax extension
On Sun, 21 Oct 2007 01:43:51 +0200 (CEST) Michael Van Canneyt [EMAIL PROTECTED] wrote: On Sun, 21 Oct 2007, Mattias Gaertner wrote: On Sun, 21 Oct 2007 00:46:19 +0200 (CEST) Michael Van Canneyt [EMAIL PROTECTED] wrote: On Sat, 20 Oct 2007, Mattias Gaertner wrote: On Sat, 20 Oct 2007 16:29:40 +0200 Tomas Hajny [EMAIL PROTECTED] wrote: On 19 Oct 07, at 13:14, Micha Nelissen wrote: Jonas Maebe wrote: This is not true. You can perfectly compile a compiler using the previous' release rtl. Sure this is not the question. E.g. the people developing using the fp IDE often do this (because they have a project for the compiler, but that one does not automatically compile the rtl). Adapt the project to use the new RTL ? Anyway, seems dangerous to me, not testing possible RTL regressions then. A while ago, Peter removed several dependencies of the compiler on the new rtl (related to endian swapping routines) for this reason. I see the reason is not really coming out, but I'll stop now. Well, I'd certainly have one (more) reason not to put it into RTL - I don't think that support for .ppu file format is something so general and commonly used by (Free) Pascal programmers that it should become part of our RTL. And another: A lazarus built with fpc 2.0.4 should be able to read the ppu of 2.3.x. Even though the ppu format is very stable, it is not carved in stone. It's built so that a newer version can always read an older PPU file and vice versa: an old ppu unit can read a newer file, but just doesn't know how to interpret certain blocks. Are we talking about a complete ppu parser or something to only read the property info? Well, the ppu file is divided in blocks; Each block has a type and a size. If you don't know a block, you can 'skip' it. (If memory serves me right, of course) If the codetools can only read those fields of the ppu, that are supported by the fpc version used for building the codetools, then the ppu reader will always stay merely a fallback parser - only used if there are no sources or to check the user configuration. In this case: The property information can not be read with the released fpc 2.2. And this means probably the next years. IMHO the codetools should be able to read the ppu of all available fpc versions, independent of the fpc used compiling the codetools. So, maybe it would be best to keep a working copy of the ppu reader unit in the lazarus svn and give it a distinct name? I think such a unit could best go in the packages, since it is tightly bound to FPC, and definitely non-visual ? Well, it should be bound to FPC, but it should not be bound to a specific FPC version. Exactly. That's why we need a copy. The copy (ppuparser or whatever) can maintain knowledge of past versions, as far as that is needed. Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] property syntax extension
On Sun, 21 Oct 2007 08:36:24 +0200 (CEST) Daniël Mantione [EMAIL PROTECTED] wrote: Op Sun, 21 Oct 2007, schreef Michael Van Canneyt: .ppu file format is something so general and commonly used by (Free) Pascal programmers that it should become part of our RTL. And another: A lazarus built with fpc 2.0.4 should be able to read the ppu of 2.3.x. Even though the ppu format is very stable, it is not carved in stone. It's built so that a newer version can always read an older PPU file and vice versa: an old ppu unit can read a newer file, but just doesn't know how to interpret certain blocks. This is not true. Take for example: procedure tarraydef.ppuwrite(ppufile:tcompilerppufile); begin inherited ppuwrite(ppufile); ppufile.putderef(_elementdefderef); ppufile.putderef(rangedefderef); ppufile.putaint(lowrange); ppufile.putaint(highrange); ppufile.putsmallset(arrayoptions); ppufile.writeentry(ibarraydef); end; If the arrayoptions for example becomes a large set (32 elements), an old version that will try to read a new version will read too little data. We will of course bump the ppu version, so the compile refuses old ppus. Is the newer ppureader be able to read older ppu? In other words: Does a current ppureader contains the code to read the old format too? Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] property syntax extension
Mattias Gaertner schrieb: On Sun, 21 Oct 2007 08:36:24 +0200 (CEST) Daniël Mantione [EMAIL PROTECTED] wrote: Op Sun, 21 Oct 2007, schreef Michael Van Canneyt: .ppu file format is something so general and commonly used by (Free) Pascal programmers that it should become part of our RTL. And another: A lazarus built with fpc 2.0.4 should be able to read the ppu of 2.3.x. Even though the ppu format is very stable, it is not carved in stone. It's built so that a newer version can always read an older PPU file and vice versa: an old ppu unit can read a newer file, but just doesn't know how to interpret certain blocks. This is not true. Take for example: procedure tarraydef.ppuwrite(ppufile:tcompilerppufile); begin inherited ppuwrite(ppufile); ppufile.putderef(_elementdefderef); ppufile.putderef(rangedefderef); ppufile.putaint(lowrange); ppufile.putaint(highrange); ppufile.putsmallset(arrayoptions); ppufile.writeentry(ibarraydef); end; If the arrayoptions for example becomes a large set (32 elements), an old version that will try to read a new version will read too little data. We will of course bump the ppu version, so the compile refuses old ppus. Is the newer ppureader be able to read older ppu? In other words: Does a current ppureader contains the code to read the old format too? No. I discussed this already with Paul. My proposal is generate a separate xml file containing the attributes. This xml can be used by IDEs or included in the final executable if necessary. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] property syntax extension
Op Sun, 21 Oct 2007, schreef Mattias Gaertner: On Sun, 21 Oct 2007 08:36:24 +0200 (CEST) Is the newer ppureader be able to read older ppu? In other words: Does a current ppureader contains the code to read the old format too? No, the read code is similar to the write code, no version checks. Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] property syntax extension
On Sun, 21 Oct 2007, Mattias Gaertner wrote: On Sun, 21 Oct 2007 01:43:51 +0200 (CEST) Michael Van Canneyt [EMAIL PROTECTED] wrote: On Sun, 21 Oct 2007, Mattias Gaertner wrote: On Sun, 21 Oct 2007 00:46:19 +0200 (CEST) Michael Van Canneyt [EMAIL PROTECTED] wrote: On Sat, 20 Oct 2007, Mattias Gaertner wrote: On Sat, 20 Oct 2007 16:29:40 +0200 Tomas Hajny [EMAIL PROTECTED] wrote: On 19 Oct 07, at 13:14, Micha Nelissen wrote: Jonas Maebe wrote: This is not true. You can perfectly compile a compiler using the previous' release rtl. Sure this is not the question. E.g. the people developing using the fp IDE often do this (because they have a project for the compiler, but that one does not automatically compile the rtl). Adapt the project to use the new RTL ? Anyway, seems dangerous to me, not testing possible RTL regressions then. A while ago, Peter removed several dependencies of the compiler on the new rtl (related to endian swapping routines) for this reason. I see the reason is not really coming out, but I'll stop now. Well, I'd certainly have one (more) reason not to put it into RTL - I don't think that support for .ppu file format is something so general and commonly used by (Free) Pascal programmers that it should become part of our RTL. And another: A lazarus built with fpc 2.0.4 should be able to read the ppu of 2.3.x. Even though the ppu format is very stable, it is not carved in stone. It's built so that a newer version can always read an older PPU file and vice versa: an old ppu unit can read a newer file, but just doesn't know how to interpret certain blocks. Are we talking about a complete ppu parser or something to only read the property info? Well, the ppu file is divided in blocks; Each block has a type and a size. If you don't know a block, you can 'skip' it. (If memory serves me right, of course) If the codetools can only read those fields of the ppu, that are supported by the fpc version used for building the codetools, then the ppu reader will always stay merely a fallback parser - only used if there are no sources or to check the user configuration. In this case: The property information can not be read with the released fpc 2.2. And this means probably the next years. IMHO the codetools should be able to read the ppu of all available fpc versions, independent of the fpc used compiling the codetools. I understand, but what do you want to say with this ? Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] property syntax extension
On Sun, 21 Oct 2007, Florian Klaempfl wrote: If the arrayoptions for example becomes a large set (32 elements), an old version that will try to read a new version will read too little data. We will of course bump the ppu version, so the compile refuses old ppus. Is the newer ppureader be able to read older ppu? In other words: Does a current ppureader contains the code to read the old format too? No. I discussed this already with Paul. My proposal is generate a separate xml file containing the attributes. This xml can be used by IDEs or included in the final executable if necessary. That was my idea of the .ppi file. Looking at all the discussion, that option now seems best. As you say, it can always be included in the binary, if someone wants it. XML would also allow to merge files easily. I'm currently looking at a resource library implementation by Giulio Bernardi, which would make that extremely easy to do. It's completely cross-platform, and looks like a very good replacement for the current ELF-only implementation (to which it is compatible). Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] property syntax extension
On Sun, 21 Oct 2007 14:22:30 +0200 (CEST) Michael Van Canneyt [EMAIL PROTECTED] wrote: [...] Well, the ppu file is divided in blocks; Each block has a type and a size. If you don't know a block, you can 'skip' it. (If memory serves me right, of course) If the codetools can only read those fields of the ppu, that are supported by the fpc version used for building the codetools, then the ppu reader will always stay merely a fallback parser - only used if there are no sources or to check the user configuration. In this case: The property information can not be read with the released fpc 2.2. And this means probably the next years. IMHO the codetools should be able to read the ppu of all available fpc versions, independent of the fpc used compiling the codetools. I understand, but what do you want to say with this ? Only that the codetools can not use a ppureader.ppu from the RTL or FCL. It can use the ppureader.pas, but not the .ppu. Or use the XML approach as Florian/Paul suggested. Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] property syntax extension
Mattias Gaertner schrieb: On Sun, 21 Oct 2007 14:22:30 +0200 (CEST) Michael Van Canneyt [EMAIL PROTECTED] wrote: [...] Well, the ppu file is divided in blocks; Each block has a type and a size. If you don't know a block, you can 'skip' it. (If memory serves me right, of course) If the codetools can only read those fields of the ppu, that are supported by the fpc version used for building the codetools, then the ppu reader will always stay merely a fallback parser - only used if there are no sources or to check the user configuration. In this case: The property information can not be read with the released fpc 2.2. And this means probably the next years. IMHO the codetools should be able to read the ppu of all available fpc versions, independent of the fpc used compiling the codetools. I understand, but what do you want to say with this ? Only that the codetools can not use a ppureader.ppu from the RTL or FCL. It can use the ppureader.pas, but not the .ppu. Or use the XML approach as Florian I suggested :) Paul didn't like it that much He started also a wiki page: http://wiki.freepascal.org/Property_attributes /Paul suggested. Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] property syntax extension
One way to read .ppu files from multiple compiler versions would be a ppu meta file, which describes the fields written for each sym and def. The will be one meta file per ppu version. An IDE or tool that wants to read a ppu then processes the meta file for the ppu version to know how to find a certain field in the ppu. Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] property syntax extension
Florian Klaempfl wrote: Only that the codetools can not use a ppureader.ppu from the RTL or FCL. It can use the ppureader.pas, but not the .ppu. Or use the XML approach as Florian I suggested :) Paul didn't like it that much He started also a wiki page: http://wiki.freepascal.org/Property_attributes I still thinking that RTTI is much more useful than separate files. To use separate files you need some framework to find them and parse. If it is RTTI then existing tools can be easily extended to use new feature. In case of Lazarus ppu, xml, rtti is not so different. But lets think of other applications of property attributes. For example FastScript components (scripting engine of FastReports co.) use RTTI to automatically describe pascal classes in order to use them in script. Property attributes can store descriptions, value area, and another useful info. Or my example with database components. TxxxDatabase = class property TransactionModel: TTransactionModel attributes ['engines: ms-sql, oracle, sybase-asa']; end; Using such attribute database components can easily check whether this property applied to current engine. If this is stored in ppu, xml it will not used by component developers. And once again - for Lazarus it is not a big difference. Best regards, Paul Ishenin. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] property syntax extension
On Sun, 21 Oct 2007 21:55:45 +0800 Paul Ishenin [EMAIL PROTECTED] wrote: Florian Klaempfl wrote: Only that the codetools can not use a ppureader.ppu from the RTL or FCL. It can use the ppureader.pas, but not the .ppu. Or use the XML approach as Florian I suggested :) Paul didn't like it that much He started also a wiki page: http://wiki.freepascal.org/Property_attributes I still thinking that RTTI is much more useful than separate files. To use separate files you need some framework to find them and parse. If it is RTTI then existing tools can be easily extended to use new feature. In case of Lazarus ppu, xml, rtti is not so different. But lets think of other applications of property attributes. For example FastScript components (scripting engine of FastReports co.) use RTTI to automatically describe pascal classes in order to use them in script. Property attributes can store descriptions, value area, and another useful info. Or my example with database components. TxxxDatabase = class property TransactionModel: TTransactionModel attributes ['engines: ms-sql, oracle, sybase-asa']; end; Using such attribute database components can easily check whether this property applied to current engine. If this is stored in ppu, xml it will not used by component developers. And once again - for Lazarus it is not a big difference. I got a practical question: Where and how should the hint be used/shown in the OI? If it is queried only manually (e.g. user moves mouse over property and waits for a hint), then a find declaration can be done and the comment next to the property can be shown. That's easy and we don't need any change or new syntax. OTOH if you want to check these flags in property editors to color misused properties, then TPropertyEditors must be extended. Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] property syntax extension
Mattias Gaertner wrote: On Sun, 21 Oct 2007 21:55:45 +0800 Paul Ishenin [EMAIL PROTECTED] wrote: Florian Klaempfl wrote: Only that the codetools can not use a ppureader.ppu from the RTL or FCL. It can use the ppureader.pas, but not the .ppu. Or use the XML approach as Florian I suggested :) Paul didn't like it that much He started also a wiki page: http://wiki.freepascal.org/Property_attributes I still thinking that RTTI is much more useful than separate files. To use separate files you need some framework to find them and parse. If it is RTTI then existing tools can be easily extended to use new feature. In case of Lazarus ppu, xml, rtti is not so different. But lets think of other applications of property attributes. For example FastScript components (scripting engine of FastReports co.) use RTTI to automatically describe pascal classes in order to use them in script. Property attributes can store descriptions, value area, and another useful info. Or my example with database components. TxxxDatabase = class property TransactionModel: TTransactionModel attributes ['engines: ms-sql, oracle, sybase-asa']; end; Using such attribute database components can easily check whether this property applied to current engine. If this is stored in ppu, xml it will not used by component developers. And once again - for Lazarus it is not a big difference. I got a practical question: Where and how should the hint be used/shown in the OI? If it is queried only manually (e.g. user moves mouse over property and waits for a hint), then a find declaration can be done and the comment next to the property can be shown. That's easy and we don't need any change or new syntax. OTOH if you want to check these flags in property editors to color misused properties, then TPropertyEditors must be extended. Such properties can be moved to separate Tab of object expector (like Events and Favorites) or marked with color. Best regards, Paul Ishenin. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] property syntax extension
Florian Klaempfl wrote: Mattias Gaertner schrieb: On Sun, 21 Oct 2007 08:36:24 +0200 (CEST) Daniël Mantione [EMAIL PROTECTED] wrote: Op Sun, 21 Oct 2007, schreef Michael Van Canneyt: .ppu file format is something so general and commonly used by (Free) Pascal programmers that it should become part of our RTL. And another: A lazarus built with fpc 2.0.4 should be able to read the ppu of 2.3.x. Even though the ppu format is very stable, it is not carved in stone. It's built so that a newer version can always read an older PPU file and vice versa: an old ppu unit can read a newer file, but just doesn't know how to interpret certain blocks. This is not true. Take for example: procedure tarraydef.ppuwrite(ppufile:tcompilerppufile); begin inherited ppuwrite(ppufile); ppufile.putderef(_elementdefderef); ppufile.putderef(rangedefderef); ppufile.putaint(lowrange); ppufile.putaint(highrange); ppufile.putsmallset(arrayoptions); ppufile.writeentry(ibarraydef); end; If the arrayoptions for example becomes a large set (32 elements), an old version that will try to read a new version will read too little data. We will of course bump the ppu version, so the compile refuses old ppus. Is the newer ppureader be able to read older ppu? In other words: Does a current ppureader contains the code to read the old format too? No. I discussed this already with Paul. My proposal is generate a separate xml file containing the attributes. This xml can be used by IDEs or included in the final executable if necessary. I discussed with Paul to and I'm not really pro reading and parsing yet another file. Since I think attibutes are valid for more than only published properties/methods putting them in RTTi would be to limited. Besides that, as already stated, it's not really necesary to put this info in the final executable. Therefore I suggested to put the info in the ppu, something what popped up in a previous discussion. IMO, lazarus will be capabable of reading ppus someday to get rid of the requirement that you can only have autocompletion etc. when all the sources are readable and parsable. From the current discussion I realize that different versions of ppu files need to be parsed, current formats and future formats. The latter case will bring some difficulties. With this in mind, I think indeed that a compiler generated second file with xml info about the unit is a better solution. Given that all the info a 3rd party like lazarus would read from source or ppu would be available in that info file. This way all info is quickly available by one file. Marc ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] property syntax extension
On 19 Oct 07, at 13:14, Micha Nelissen wrote: Jonas Maebe wrote: This is not true. You can perfectly compile a compiler using the previous' release rtl. Sure this is not the question. E.g. the people developing using the fp IDE often do this (because they have a project for the compiler, but that one does not automatically compile the rtl). Adapt the project to use the new RTL ? Anyway, seems dangerous to me, not testing possible RTL regressions then. A while ago, Peter removed several dependencies of the compiler on the new rtl (related to endian swapping routines) for this reason. I see the reason is not really coming out, but I'll stop now. Well, I'd certainly have one (more) reason not to put it into RTL - I don't think that support for .ppu file format is something so general and commonly used by (Free) Pascal programmers that it should become part of our RTL. Tomas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] property syntax extension
On Sat, 20 Oct 2007 16:29:40 +0200 Tomas Hajny [EMAIL PROTECTED] wrote: On 19 Oct 07, at 13:14, Micha Nelissen wrote: Jonas Maebe wrote: This is not true. You can perfectly compile a compiler using the previous' release rtl. Sure this is not the question. E.g. the people developing using the fp IDE often do this (because they have a project for the compiler, but that one does not automatically compile the rtl). Adapt the project to use the new RTL ? Anyway, seems dangerous to me, not testing possible RTL regressions then. A while ago, Peter removed several dependencies of the compiler on the new rtl (related to endian swapping routines) for this reason. I see the reason is not really coming out, but I'll stop now. Well, I'd certainly have one (more) reason not to put it into RTL - I don't think that support for .ppu file format is something so general and commonly used by (Free) Pascal programmers that it should become part of our RTL. And another: A lazarus built with fpc 2.0.4 should be able to read the ppu of 2.3.x. Even though the ppu format is very stable, it is not carved in stone. So, maybe it would be best to keep a working copy of the ppu reader unit in the lazarus svn and give it a distinct name? Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] property syntax extension
Op Sat, 20 Oct 2007, schreef Mattias Gaertner: And another: A lazarus built with fpc 2.0.4 should be able to read the ppu of 2.3.x. Even though the ppu format is very stable, it is not carved in stone. So, maybe it would be best to keep a working copy of the ppu reader unit in the lazarus svn and give it a distinct name? Only the global structure stays the same. Fields are being added and removed from defs and syms all the time and compiler development progresses. Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] property syntax extension
On Sat, 20 Oct 2007 23:55:31 +0200 (CEST) Daniël Mantione [EMAIL PROTECTED] wrote: Op Sat, 20 Oct 2007, schreef Mattias Gaertner: And another: A lazarus built with fpc 2.0.4 should be able to read the ppu of 2.3.x. Even though the ppu format is very stable, it is not carved in stone. So, maybe it would be best to keep a working copy of the ppu reader unit in the lazarus svn and give it a distinct name? Only the global structure stays the same. Fields are being added and removed from defs and syms all the time and compiler development progresses. Then I vote for using a copy, which is manually updated from time to time. Coming back to the real problem: Searching and reading the ppu is as expensive as reading the sources or reading the fpdoc xml files. So, there is no need to put the property information into the ppu - except for closed sources. RTTI: The RTTI as storage has the advantage, that you don't need to explore the code. Comment/Pragma/IDE directive: Using a 'comment' has the disadvantage of expensive finding/reading the source and the advantage, that you don't need the ppu (easier cross exploring, more independent of missing units). Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] property syntax extension
On Sun, 21 Oct 2007 00:46:19 +0200 (CEST) Michael Van Canneyt [EMAIL PROTECTED] wrote: On Sat, 20 Oct 2007, Mattias Gaertner wrote: On Sat, 20 Oct 2007 16:29:40 +0200 Tomas Hajny [EMAIL PROTECTED] wrote: On 19 Oct 07, at 13:14, Micha Nelissen wrote: Jonas Maebe wrote: This is not true. You can perfectly compile a compiler using the previous' release rtl. Sure this is not the question. E.g. the people developing using the fp IDE often do this (because they have a project for the compiler, but that one does not automatically compile the rtl). Adapt the project to use the new RTL ? Anyway, seems dangerous to me, not testing possible RTL regressions then. A while ago, Peter removed several dependencies of the compiler on the new rtl (related to endian swapping routines) for this reason. I see the reason is not really coming out, but I'll stop now. Well, I'd certainly have one (more) reason not to put it into RTL - I don't think that support for .ppu file format is something so general and commonly used by (Free) Pascal programmers that it should become part of our RTL. And another: A lazarus built with fpc 2.0.4 should be able to read the ppu of 2.3.x. Even though the ppu format is very stable, it is not carved in stone. It's built so that a newer version can always read an older PPU file and vice versa: an old ppu unit can read a newer file, but just doesn't know how to interpret certain blocks. Are we talking about a complete ppu parser or something to only read the property info? So, maybe it would be best to keep a working copy of the ppu reader unit in the lazarus svn and give it a distinct name? I think such a unit could best go in the packages, since it is tightly bound to FPC, and definitely non-visual ? Well, it should be bound to FPC, but it should not be bound to a specific FPC version. Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] property syntax extension
On Sun, 21 Oct 2007, Mattias Gaertner wrote: On Sun, 21 Oct 2007 00:46:19 +0200 (CEST) Michael Van Canneyt [EMAIL PROTECTED] wrote: On Sat, 20 Oct 2007, Mattias Gaertner wrote: On Sat, 20 Oct 2007 16:29:40 +0200 Tomas Hajny [EMAIL PROTECTED] wrote: On 19 Oct 07, at 13:14, Micha Nelissen wrote: Jonas Maebe wrote: This is not true. You can perfectly compile a compiler using the previous' release rtl. Sure this is not the question. E.g. the people developing using the fp IDE often do this (because they have a project for the compiler, but that one does not automatically compile the rtl). Adapt the project to use the new RTL ? Anyway, seems dangerous to me, not testing possible RTL regressions then. A while ago, Peter removed several dependencies of the compiler on the new rtl (related to endian swapping routines) for this reason. I see the reason is not really coming out, but I'll stop now. Well, I'd certainly have one (more) reason not to put it into RTL - I don't think that support for .ppu file format is something so general and commonly used by (Free) Pascal programmers that it should become part of our RTL. And another: A lazarus built with fpc 2.0.4 should be able to read the ppu of 2.3.x. Even though the ppu format is very stable, it is not carved in stone. It's built so that a newer version can always read an older PPU file and vice versa: an old ppu unit can read a newer file, but just doesn't know how to interpret certain blocks. Are we talking about a complete ppu parser or something to only read the property info? Well, the ppu file is divided in blocks; Each block has a type and a size. If you don't know a block, you can 'skip' it. (If memory serves me right, of course) So, maybe it would be best to keep a working copy of the ppu reader unit in the lazarus svn and give it a distinct name? I think such a unit could best go in the packages, since it is tightly bound to FPC, and definitely non-visual ? Well, it should be bound to FPC, but it should not be bound to a specific FPC version. Exactly. That's why we need a copy. The copy (ppuparser or whatever) can maintain knowledge of past versions, as far as that is needed. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] property syntax extension
function func:integer; cdecl; Most of the time yes, sometime no like the following : procedure proc( CONST AParametter : integer ); IMHO this time, Delphi compatibility is a very strong point. Is there anything to be compatible with? Does Delphi/win32 use this in any way? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] property syntax extension
Jonas Maebe wrote: This is not true. You can perfectly compile a compiler using the previous' release rtl. Sure this is not the question. E.g. the people developing using the fp IDE often do this (because they have a project for the compiler, but that one does not automatically compile the rtl). Adapt the project to use the new RTL ? Anyway, seems dangerous to me, not testing possible RTL regressions then. A while ago, Peter removed several dependencies of the compiler on the new rtl (related to endian swapping routines) for this reason. I see the reason is not really coming out, but I'll stop now. Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] property syntax extension
Is there anything to be compatible with? Yes, that is syntax used by Delphi.Net Does Delphi/win32 use this in any way? No, but if someday Delphi/win32 has to support attributes it will certainly use the same syntax and FPC will be ready. -- Inoussa O. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] property syntax extension
On 19 Oct 2007, at 11:21, Micha Nelissen wrote: Jonas Maebe wrote: On 19 Oct 2007, at 11:00, Micha Nelissen wrote: Elaborate please ? You mean debugging of the compiler, but don't you always work on new compilers ? When debugging, you could copy the ppu to the old RTL if you're using an old RTL with a new compiler ? My global install of FPC 2.2.0 does not include this unit. Compiling it with 2.2.0 and adding it to my global installation is what I consider needlessly complex This was not my intention. I thought you meant with debugging difficulty you were trying to debug the RTL by comparing the compiler behaviour with two different RTLs or so. Since the compiler is always compiled using its own RTL This is not true. You can perfectly compile a compiler using the previous' release rtl. E.g. the people developing using the fp IDE often do this (because they have a project for the compiler, but that one does not automatically compile the rtl). A while ago, Peter removed several dependencies of the compiler on the new rtl (related to endian swapping routines) for this reason. Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] property syntax extension
On 19 Oct 2007, at 11:00, Micha Nelissen wrote: Jonas Maebe wrote: It's not a good idea to make the compiler dependent on features not available in the RTL of the previous release, as this can complicate debugging quite a bit. Elaborate please ? You mean debugging of the compiler, but don't you always work on new compilers ? When debugging, you could copy the ppu to the old RTL if you're using an old RTL with a new compiler ? My global install of FPC 2.2.0 does not include this unit. Compiling it with 2.2.0 and adding it to my global installation is what I consider needlessly complex (not to mention that it pollutes my 2.2.0 install so I can no longer use it to test 2.2.0 bug reports, as I may see different things than someone who installed the actual release), and this practice can easily lead to a complete mess of cascade dependencies on newer versions of units (hoping in case such a unit in itself also starts depending on other new features of the new RTL). Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] property syntax extension
But IMHO, if a new langage feature have to be introduced, a feature already implemented in Delphi, it will be good to make it compatible. Mainly for code sharing. There already is a Delphi compatibility compiler switch. There could be a Delphi.NET (and maybe a Chrome) compatibility compiler switch that allows for the appropriate syntax (and maybe disables incompatible native FP syntax). But why? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] property syntax extension
On Fri, 19 Oct 2007, Paul Ishenin wrote: Michael Van Canneyt wrote: Ok, no problem - lets it be ppu. We only need some way of accessing that data. Is ppu reading methods already exists in RTL or another fpc package? The ppu unit does what you need. It is used by the compiler and dumppu program provided by FPC. Maybe we should make a copy of this unit in the packages, and extend it with some search methods/classes. I dont like idea of maintaining code more than in one place. The best way is to create sone unit to read/write that ppu files and use it in all places: in compiler, dumppu and later in lazarus. Of maybe it is not possible (for fpc I am simple user)? Well, the unit is in the compiler directory, and is not meant for distribution. It can only be in the compiler directory, otherwise it's impossible to bootstrap the compiler (i.e. compile the compiler the first time). Btw, is proposed syntax need modification or it looks ok? For me it is OK. It's more pascal than the construct introduced in Delphi. It's also more like the construct we use for procedures [public,Alias:'some']; and interfaces [GUID], so for me this is very OK. If you implement this, I suggest you also implement it in pscanner in fcl-passrc, or fpdoc will stop working as soon as you use it in the LCL. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] property syntax extension
On 19 Oct 2007, at 13:14, Micha Nelissen wrote: Jonas Maebe wrote: This is not true. You can perfectly compile a compiler using the previous' release rtl. Sure this is not the question. It is the question because this is actually done by several people. E.g. the people developing using the fp IDE often do this (because they have a project for the compiler, but that one does not automatically compile the rtl). Adapt the project to use the new RTL ? Anyway, seems dangerous to me, not testing possible RTL regressions then. It's exactly the other way around: you do this when there is a bug in the compiler, and want to exclude extra variables (such as the new rtl) from the equation in order to make it easier to find the bug. You don't do this for testsuite runs. Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] property syntax extension
Michael Van Canneyt wrote: Well, the unit is in the compiler directory, and is not meant for distribution. It can only be in the compiler directory, otherwise it's impossible to bootstrap the compiler (i.e. compile the compiler the first time). The RTL is always compiled before the compiler is, so the compiler can use the new RTL. Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] property syntax extension
On Fri, 19 Oct 2007, Jonas Maebe wrote: On 19 Oct 2007, at 10:28, Micha Nelissen wrote: Michael Van Canneyt wrote: Well, the unit is in the compiler directory, and is not meant for distribution. It can only be in the compiler directory, otherwise it's impossible to bootstrap the compiler (i.e. compile the compiler the first time). The RTL is always compiled before the compiler is, so the compiler can use the new RTL. It's not a good idea to make the compiler dependent on features not available in the RTL of the previous release, as this can complicate debugging quite a bit. Indeed. In this particular case, the code duplication is just a safety precaution. It also allows us to change the interface of the 'public' ppu file at will, so it is more suitable for use in the IDE or whatever library requires it. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] property syntax extension
Jonas Maebe wrote: It's not a good idea to make the compiler dependent on features not available in the RTL of the previous release, as this can complicate debugging quite a bit. Elaborate please ? You mean debugging of the compiler, but don't you always work on new compilers ? When debugging, you could copy the ppu to the old RTL if you're using an old RTL with a new compiler ? Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] property syntax extension
Paul Ishenin wrote: Attached file (open document format can be opened by OpenOffice) contains proposed syntax diagrams and declaration examples. Sorry, seems odt is not well known format but hope rtf is :( In attach same file in rtf. Best regards, Paul Ishenin. property_attributes.rtf Description: MS-Word document ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] property syntax extension
On 18/10/2007, Paul Ishenin [EMAIL PROTECTED] wrote: Later Florian in private conversation with me suggested better idea of property attributes. Indeed, attributes are more general solution than platform keyword. That's a very interesting idea. I can see many uses for it, especially if you can query the values via RTTI. BTW: Is that something similar to what VB6 (I think) does. I remember from many years back that when you selected a property to edit, in the bottom of the Object Inspector (whatever it was called in VB) it showed a description of that property. As far as I remember that description was part of the class definition - Delphi never supported something like that. 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] property syntax extension
Graeme Geldenhuys wrote: VB) it showed a description of that property. As far as I remember that description was part of the class definition - Delphi never supported something like that. I don't think you want to carry around complete property descriptions in your final executables ;-). Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] property syntax extension
Micha Nelissen пишет: Graeme Geldenhuys wrote: VB) it showed a description of that property. As far as I remember that description was part of the class definition - Delphi never supported something like that. I don't think you want to carry around complete property descriptions in your final executables ;-). Later we can invent new switch to control inclusion of such extended rtti into final executable. Best regards, Paul Ishenin. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] property syntax extension
Marc Weustink пишет: Micha Nelissen wrote: Graeme Geldenhuys wrote: VB) it showed a description of that property. As far as I remember that description was part of the class definition - Delphi never supported something like that. I don't think you want to carry around complete property descriptions in your final executables ;-). IMO rtti is not strictly needed for this concept. It could also go the the ppu (and then you can apply attributes to more symbols) Maybe the problem is that I dont know what is ppu (yes, I saw such extension on my file system) and how to query that ppu from lazarus. Best regards, Paul Ishenin. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] property syntax extension
odt is not well known format Open Document format is an ISO standard. (That is why Microsoft's Open XML hopefully will not be accepted as a concurrent standard for the same purpose.) -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] property syntax extension
On 18/10/2007, Paul Ishenin [EMAIL PROTECTED] wrote: Michael Schnell пишет: odt is not well known format Open Document format is an ISO standard. yes, I know, but at least two developers complained about it, so rtf for those who have no OpenOffice. To those two developers It's FREE. Download it and get with the program! ;-) I bet you those two are MS Office users [..ducking and hiding..] 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] property syntax extension
Michael Schnell schreef: I bet you those two are MS Office users [..ducking and hiding..] Should be no problem at all. AFAIK (I'm not an MS-Office user :-) ), there is a free plugin that enables even M$-Office to read and write standard conform files (i.e. Open Document ODT). I think it is better to send a RTF document than a ODT document: * it is smaller * more programs can read it * no need to download and install plug-ins for a seizable minority of people without open office or ODT-plug-in installed. Vincent ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] property syntax extension
I think it is better to send a RTF document than a ODT document: * it is smaller * more programs can read it * no need to download and install plug-ins for a seizable minority of people without open office or ODT-plug-in installed. Valid considerations, but regarding this, PDF is a much better option. (BTW.: Open Office does write PDF without any plugins or external programs.) -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] property syntax extension
Michael Schnell schreef: I think it is better to send a RTF document than a ODT document: * it is smaller * more programs can read it * no need to download and install plug-ins for a seizable minority of people without open office or ODT-plug-in installed. Valid considerations, but regarding this, PDF is a much better option. (BTW.: Open Office does write PDF without any plugins or external programs.) Except, if you want others to extend / adjust / improve your document. In that case PDF is worthless. Vincent ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] property syntax extension
On Thu, 18 Oct 2007, Vincent Snijders wrote: Michael Schnell schreef: I bet you those two are MS Office users [..ducking and hiding..] Should be no problem at all. AFAIK (I'm not an MS-Office user :-) ), there is a free plugin that enables even M$-Office to read and write standard conform files (i.e. Open Document ODT). I think it is better to send a RTF document than a ODT document: * it is smaller * more programs can read it * no need to download and install plug-ins for a seizable minority of people without open office or ODT-plug-in installed. Then why have a standard, if no-one is going to use it ? Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] property syntax extension
On Thursday 18 October 2007 12:55, Michael Schnell wrote: I think it is better to send a RTF document than a ODT document: * it is smaller * more programs can read it * no need to download and install plug-ins for a seizable minority of people without open office or ODT-plug-in installed. Valid considerations, but regarding this, PDF is a much better option. (BTW.: Open Office does write PDF without any plugins or external programs.) Oh, come on. An OpenOffice created PDF would have had about 30K+ size after base64 encode. :P And that for data which could most easily have been provided as plain text inside the mail: -- 8 -- PropertyDeclaration ::= PROPERTY Identifier [PropertyInterface] [PropertySpecifiers] [Directives] PropertySpecifiers ::= [ ... ] [ ... ] [ATTRIBUTES AttributesArray] AttributesArray ::= '[' (AttributeDeclaration [, AttributeDeclaration]) ']' AttributeDeclaration ::= string':'string Declaration examples: TmenuItem = class(...) ... property Detachable: Boolean read FDetachable write SetDetachable attributes ['widgetsets:qt,gtk,win32', 'implementor:Vasya Pupkin', 'creation-date:01.01.2007']; ... end; TxxxDatabase = class(...) ... property TransactionModel: TTransactionModel read FtransactionModel write SetTransactionModel attributes ['engines:firebird,oracle,sybase-asa']; ... end; -- 8 -- Of course, the syntax highlighting is now missing but as the intended target audience are the developers and not managers, the missing blue won't lose you information, I'd say. VinHow big is that whole mail now?zent. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] property syntax extension
One simple idea I just had is that this could be added to the documentation. The IDE can look at the docs and show whatever is needed for each different property on each class. The downside is that the component would require docs in the same format as the lcl/rtc/fcl ones, althougth that shouldn't be a big problem. The good thing is that no new language feature is needed. regards, -- Felipe Monteiro de Carvalho ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] property syntax extension
On Thu, 18 Oct 2007, Paul Ishenin wrote: Michael Van Canneyt wrote: On Thu, 18 Oct 2007, Paul Ishenin wrote: Hello, fpc-developer list. Some time ago I posted here proposal to extend platform keyword. You gave a hostile reception to that proposal. Later Florian in private conversation with me suggested better idea of property attributes. Indeed, attributes are more general solution than platform keyword. Lets discuss this proposal. What is the purpose: extend rtti (or another structures that can be accessed at run time) with list of user defined Name=Value items. How it can be used: since it is generic solution different tools can use it in their own way. For example in LCL we can use attribute 'widgetset' to define widgetset specific properties and show such properties on another Tab of Object Inspector or with different colors (or show hints and so on). I see no problem with this proposal from a language point of view. The only problem is the storage. Your 'runtime access'. I don't think it belongs in the RTTI. RTTI ends up in the binary, and we get already enough complaints about binary size. A switch to leave it out is not really a good solution, it shouldn't be in there in the first place (apart from the technical feasability) Also, the only place where this extended information is useful, is in the Lazarus IDE (or any other IDE) Therefor I propose to simply write it to the .ppu file, or - like the resource strings - to a separate file: one per unit. (a .ppi file: pascal property information). Ok, no problem - lets it be ppu. We only need some way of accessing that data. Is ppu reading methods already exists in RTL or another fpc package? The ppu unit does what you need. It is used by the compiler and dumppu program provided by FPC. Maybe we should make a copy of this unit in the packages, and extend it with some search methods/classes. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] property syntax extension
Felipe Monteiro de Carvalho wrote: One simple idea I just had is that this could be added to the documentation. The IDE can look at the docs and show whatever is needed for each different property on each class. The downside is that the component would require docs in the same format as the lcl/rtc/fcl ones, althougth that shouldn't be a big problem. The good thing is that no new language feature is needed. The bad thing that this will not work. I am developer Felipe, not technical writer. I dont know how to write helps and moreover I will not write them. BUT, I know what how the code work and I want an easy way to add small hints to that code (and this hints must be understanded by IDE). Moreover that hints can be used later by help/documentation tools when they will generate their output. Best regards, Paul Ishenin. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] property syntax extension
On 10/18/07, Paul Ishenin [EMAIL PROTECTED] wrote:
The bad thing that this will not work. I am developer Felipe, not
technical writer. I dont know how to write helps and moreover I will not
write them.
I actually consider that what you wish to achieve *is* documentation.
You desire to pass more information to the user of LCL then what is on
the function parameters and other code parts.
This information can be: Works on the following widgetsets: X, Y, Z
But it could also be anything else desired.
Some code documentation systems work by parsing comments which go in
the source code itself, like javadoc, and that would probably make
things easier for you as you don't need to leave the code editor to
add documentation information, and shows an advantage of this
documentation system.
If we were using such a system we could have a comment like this:
{Function X
Description: blablabla
Widgetsets: win32 wince
}
function x()
begin
I always liked the comments in-code approach a lot better, but I doubt
that we will change now.
Particularly lazarus uses lazde to edit the documentation, which is in
XML files that can be outputed into HTML files. It's not particularly
easy to work with.
The help is already integrated into the object inspector, pressing F1
shows (or attempts to) show a url with the respective docs. From there
we could extract the widgetset information or anything else and then
it can be shown this in whatever way desired.
If our current documentation system is too hard an alternative idea
would be adding a hint to the IDE on the code.
Maybe:
procedure MethodX; {%widgetsets win32 wince}
This should be quicker and easier to implement then extending the ppu files.
thanks,
--
Felipe Monteiro de Carvalho
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] property syntax extension
Felipe Monteiro de Carvalho wrote: On 10/18/07, Paul Ishenin [EMAIL PROTECTED] wrote: The bad thing that this will not work. I am developer Felipe, not technical writer. I dont know how to write helps and moreover I will not write them. I actually consider that what you wish to achieve *is* documentation. You desire to pass more information to the user of LCL then what is on the function parameters and other code parts. Actually I need this to make lazarus ide more user friendly. For example to distinct unsupported by widgetset properties from supported, to show another hints for properties (if that hints named as properties attributes are defined). Docemntation generation is just an example of another application of this nice feature. Best regards, Paul Ishenin. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] property syntax extension
(...)
Maybe:
procedure MethodX; {%widgetsets win32 wince}
This should be quicker and easier to implement then extending the ppu
files.
thanks,
--
Felipe Monteiro de Carvalho
Amen, brother Felipe ;-)
The only downside to is that it'll probably be necessary to keep some
duplicated parser code...
-Flávio
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] property syntax extension
Getting these informations at runtime is definitely a _powerful_
_feature_, it's no more than
.Net's attributes or java's annotations.
Their generation could be activated by a compiler switch like the RTTI
{$M+} and {$M-} so in debug mode it will be activated for the LCL code
and deactivated in release mode. For
example the following compiler directives could be put at the begining
of the LCL units.
So you pay for what you use, and don't have to pay and don't pay for
what you don't use.
{$IFDEF DEBUG}
{$ANNOTATION+}
{$ENDIF}
{$IFNDEF DEBUG}
{$ANNOTATION-}
{$ENDIF}
By the way why not adopt the Delphi attributes's syntax instead of
creating a new one with
incompatibilties ?
Personaly I could use it in the WST to declare entities's
serialization style (attribute
properties, embedded array, external elements names ...), SOAP
operation encoding (
litteral or encodded ), SOAPAction
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] property syntax extension
how is [...] coupled to TransactionModel ? Just because it happens to be declared the line in front of it ? Yes, the attribute declaration is placed imediately prior to the element it applies to. Example at http://hallvards.blogspot.com/2007/09/dn4dp14-net-only-attributes-support.html -- Inoussa O. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] property syntax extension
Another usage sample at http://dn.codegear.com/article/36962 In the document, the [ServiceContract] is used by the .Net runtime to define service interface( see bellow ). type [ServiceContract] ISimpleCalc = interface [OperationContract] function Add(a, b: integer): integer; [OperationContract] function Subtract(a, b: integer): integer; end; -- Inoussa O. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] property syntax extension
Inoussa OUEDRAOGO wrote: so the sample code becomes ( using Delphi's attribute syntax ) TxxxDatabase = class(...) ... [Engines(List='firebird,oracle,sybase-asa')] property TransactionModel: TTransactionModel read FtransactionModel write SetTransactionModel; ... end; That doesn't look like language syntax to me, more like a comment? Isn't property TransactionModel: TTransactionModel read FtransactionModel write SetTransactionModel attribute Engines: List = 'firebird,oracle,sybase-asa'; much more logical ? Micha ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] property syntax extension
On Thu, 18 Oct 2007, Micha Nelissen wrote: Inoussa OUEDRAOGO wrote: so the sample code becomes ( using Delphi's attribute syntax ) TxxxDatabase = class(...) ... [Engines(List='firebird,oracle,sybase-asa')] property TransactionModel: TTransactionModel read FtransactionModel write SetTransactionModel; ... end; That doesn't look like language syntax to me, more like a comment? Isn't property TransactionModel: TTransactionModel read FtransactionModel write SetTransactionModel attribute Engines: List = 'firebird,oracle,sybase-asa'; much more logical ? Indeed. Exactly my point. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] property syntax extension
Micha Nelissen wrote:
Inoussa OUEDRAOGO wrote:
so the sample code becomes ( using Delphi's attribute syntax )
TxxxDatabase = class(...)
...
[Engines(List='firebird,oracle,sybase-asa')]
property TransactionModel: TTransactionModel read FtransactionModel
write SetTransactionModel;
...
end;
That doesn't look like language syntax to me, more like a comment?
exactly my idea, even more since [{ are pretty similar
otoh, it looks a bit like a pragma now
Marc
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] property syntax extension
property TransactionModel: TTransactionModel read FtransactionModel write SetTransactionModel attribute Engines: List = 'firebird,oracle,sybase-asa'; much more logical ? As attributes is meant to be used with allmost any construct( class, field, property, method orprocedure parametters, method or procedure, module... ), I think it is a reasonable syntax; It IMHO isn't, since it is prefixed, like C#, while Pascal (AND variants) usually have directives and modifiers AFTER the keyword. __cdecl int func(void) vs function func:integer; cdecl; ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] property syntax extension
function func:integer; cdecl; Most of the time yes, sometime no like the following : procedure proc( CONST AParametter : integer ); IMHO this time, Delphi compatibility is a very strong point. -- Inoussa O. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] property syntax extension
Op Thu, 18 Oct 2007, schreef Inoussa OUEDRAOGO: function func:integer; cdecl; Most of the time yes, sometime no like the following : procedure proc( CONST AParametter : integer ); IMHO this time, Delphi compatibility is a very strong point. It is a strong point. On the other hard keeping the language clean is an important responsible task we have. We never planned to be compatible with Delphi.NET. (I have never considered Delphi.NET a real Pascal implementation; it departs rather far from what Wirth designed). While .NET features will spread to native code I'd like to consider native code features only. Some may originate from .NET in the end, and can be considered, but only because thy have become native Delphi features. Daniël___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] property syntax extension
On 10/18/07, Inoussa OUEDRAOGO [EMAIL PROTECTED] wrote: It is a strong point. On the other hard keeping the language clean is an important responsible task we have. We never planned to be compatible with Delphi.NET. (I have never considered Delphi.NET a real Pascal implementation; it departs rather far from what Wirth designed). While .NET features will spread to native code I'd like to consider native code features only. Some may originate from .NET in the end, and can be considered, but only because thy have become native Delphi features. I have a great respect toward FPC devel team. And I do anderstand and respect that FPC team do not plan to be compatible with Delphi.Net. But IMHO, if a new langage feature have to be introduced, a feature already implemented in Delphi, it will be good to make it compatible. Mainly for code sharing. -- Inoussa O. I tend to agree, but Borland has neglected Delphi for so long that I really wonder if anything above Delphi7 (or even D5) is truly relevant... -Flávio ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] property syntax extension
Michael Van Canneyt wrote: Ok, no problem - lets it be ppu. We only need some way of accessing that data. Is ppu reading methods already exists in RTL or another fpc package? The ppu unit does what you need. It is used by the compiler and dumppu program provided by FPC. Maybe we should make a copy of this unit in the packages, and extend it with some search methods/classes. I dont like idea of maintaining code more than in one place. The best way is to create sone unit to read/write that ppu files and use it in all places: in compiler, dumppu and later in lazarus. Of maybe it is not possible (for fpc I am simple user)? Btw, is proposed syntax need modification or it looks ok? Best regards, Paul Ishenin. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] property syntax extension
Marco van de Voort wrote: These idiots had to do it totally against the Pascal Language specs. This is not Pascal language anymore. This is Delphi language. Delphi or Delphi.NET? Does native Delphi do more with it than ignore it? Delphi.net in this case. (like the dotted unit names introduced in D7) Yup. D7 introduced the Delphi Language and killed Object Pascal, perhaps because of the .net stuff. -- Joao Morais ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] property syntax extension
It is a strong point. On the other hard keeping the language clean is an important responsible task we have. We never planned to be compatible with Delphi.NET. (I have never considered Delphi.NET a real Pascal implementation; it departs rather far from what Wirth designed). While .NET features will spread to native code I'd like to consider native code features only. Some may originate from .NET in the end, and can be considered, but only because thy have become native Delphi features. I have a great respect toward FPC devel team. And I do anderstand and respect that FPC team do not plan to be compatible with Delphi.Net. But IMHO, if a new langage feature have to be introduced, a feature already implemented in Delphi, it will be good to make it compatible. Mainly for code sharing. -- Inoussa O. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] property syntax extension
Hello, fpc-developer list. Some time ago I posted here proposal to extend platform keyword. You gave a hostile reception to that proposal. Later Florian in private conversation with me suggested better idea of property attributes. Indeed, attributes are more general solution than platform keyword. Lets discuss this proposal. What is the purpose: extend rtti (or another structures that can be accessed at run time) with list of user defined Name=Value items. How it can be used: since it is generic solution different tools can use it in their own way. For example in LCL we can use attribute 'widgetset' to define widgetset specific properties and show such properties on another Tab of Object Inspector or with different colors (or show hints and so on). Attached file (open document format can be opened by OpenOffice) contains proposed syntax diagrams and declaration examples. -- Best regards, Paul Ishenin. property_attributes.odt Description: application/vnd.oasis.opendocument.text ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
