[fpc-pascal] Typinfo incompatibilities between FPC and Delphi
I'm attempting to port GExperts from Delphi to Lazaurus and noticed the definition of TPropInfo differs from Delphi's. In FPC's TPropInfo the PropType field is PTypeInfo whereas in Delphi it is PPTypeInfo. I'm not sure what is actually gained by this extra level of indirection but it exists none the less. Are there any plans to update TPropInfo to be compatible with Delphi or do I need to wrap dependent code with compiler conditionals? ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: [Lazarus] Should TObject or TComponent have a Comment property?
On Wed, Jul 17, 2013 at 4:24 PM, Kenneth Cochran kenneth.coch...@gmail.comwrote: On Wed, Jul 17, 2013 at 3:53 AM, Mattias Gaertner nc-gaert...@netcologne.de wrote: Do you mean hovering over the component in the designer? At the moment the hint shows only the caption and some common values. It could be extended to show the help for the variable. Feel free to create a feature request. I think he's referring to hovering over the component icon on the component pallet. Right now the tool tip shows the class name and the unit it is defined in. I think he wants it extended to include a description of the component's purpose. So hovering over the TButton icon would display: TButton (StdCtrls) A push button control. I'm all for making components more discover-able but I don't think increasing the memory footprint of every control with a comment or description field is the right solution. Using the FPDoc info already available would be a good solution. I prefer this to the JavaDoc/XMLDoc style comments in the source. I'm willing to give it a go but I've never done anything extensive with either FPDoc or the IDE internals. Anyone have a ballpark guess as to how much effort would it take to extend the tooltip for the component pallet to display the short tag from the FPDoc info? ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: [Lazarus] Should TObject or TComponent have a Comment property?
On Thu, Jul 18, 2013 at 2:22 PM, Juha Manninen juha.mannine...@gmail.comwrote: On Thu, Jul 18, 2013 at 6:26 PM, Kenneth Cochran kenneth.coch...@gmail.com wrote: Anyone have a ballpark guess as to how much effort would it take to extend the tooltip for the component pallet to display the short tag from the FPDoc info? The hint is set in unit ide/ComponentPalette, line 744 in Lazarus trunk. I don't have details for getting the FPDoc info but you can study the code yourself. It is used for example in the Object Inspector's Information Box below the properties. I don't think the feature requires much code once you have figured out where to get the needed data. This is typical in a big project. A commit with only few lines of code has required many hours of studying the existing code. Yea, I found TComponentPalette.UpdateNotebookButtons on my own in a round about way. I set a breakpoint in TControl.SetHint and launched an instance of the IDE with the debugger attached. After a half dozen hits I was into the pallet speedbuttons and checked the call stack. Now I'm trying to track down how the source editor invokes FPDoc support when you hover over an identifier. A search for FPDoc in the source turned up the CodeHelp unit. Anyone know if I'm on the right track? ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: [Lazarus] Should TObject or TComponent have a Comment property?
On Wed, Jul 17, 2013 at 3:53 AM, Mattias Gaertner nc-gaert...@netcologne.de wrote: Do you mean hovering over the component in the designer? At the moment the hint shows only the caption and some common values. It could be extended to show the help for the variable. Feel free to create a feature request. I think he's referring to hovering over the component icon on the component pallet. Right now the tool tip shows the class name and the unit it is defined in. I think he wants it extended to include a description of the component's purpose. So hovering over the TButton icon would display: TButton (StdCtrls) A push button control. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Object Pascal Grammar in EBNF like style
Just curious how your efforts turned out? On Fri, Mar 22, 2013 at 9:59 AM, Graeme Geldenhuys gra...@geldenhuys.co.ukwrote: On 2013-03-22 13:29, Michael Van Canneyt wrote: That looks dangerously much, almost verbatim, like the appendix A of the Delphi language guide as found in the D7 manual. Umm, I don't have the Delphi manuals, but I do have the Kylix 3 manuals. I see what you mean. I didn't copy it from the Kylix 3 manual though, I got it from the following URL: http://delphi.wikia.com/wiki/Object_Pascal_Grammar Would it make a difference though? EBNF for a language grammar should be pretty much identical to any other EBNF of the same language. The order of the definitions might change slightly, but the language grammar would still be the same. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Object pascal language compatiblity - was: Does FPC 2.8.0 can actually still be called Pascal ?
On Feb 28, 2013 5:23 AM, Henry Vermaak henry.verm...@gmail.com wrote: On Thu, Feb 28, 2013 at 10:45:08AM +, Graeme Geldenhuys wrote: On 2013-02-28 09:28, Marc Pertron wrote: We need better optimisations at least as much as fancy 123.tostring. Bottom line optimisation work is just not as sexy and exciting as adding the latest Delphi/Java/C#/C language features. I guess we can't blame them for that. An llvm target will move the optimisation burden away from fpc, which would be very interesting. Henry Ironically this is the direction Embarcadero is moving. They've already made the transition with their C/C++ compiler and there have been hints that Delphi is next. In a way it makes sense. They get an instant boost in runtime performance and can focus more of their resources on the compiler front end, libraries and IDE. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Object pascal language compatiblity - was: Does FPC 2.8.0 can actually still be called Pascal ?
Btw, there is already an object pascal implementation targeting llvm. https://code.google.com/p/llvm-pascal/ On Thu, Feb 28, 2013 at 8:36 AM, Marco van de Voort mar...@stack.nl wrote: In our previous episode, Kenneth Cochran said: Ironically this is the direction Embarcadero is moving. They've already made the transition with their C/C++ compiler and there have been hints that Delphi is next. In a way it makes sense. They get an instant boost in runtime performance and can focus more of their resources on the compiler front end, libraries and IDE. And, like LLVM, they only care about popular targets anyway. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Is it possible to redefine FreePascal types?
Yes. type newString = type string; Any function that accepts newString as a parameter will cause a compilation error if you try to pass a normal string. You'll have to cast it to newString first. On Wed, Nov 21, 2012 at 1:37 PM, Frank Church vfcli...@gmail.com wrote: Lets say I am using some string variables, but I want to ensure that there are no typing errors in some code I am using. so I define newString as a new string type and declare a variable as ANewString. That way if I create a function such as functionUsingNewString(a: newString) and I pass a plain string as a parameter to functionNewString the compiler declares an error. If c is string and b is newString and I do b := c the compiler should generate an error unless I do b := newString(c); Is this possible? -- Frank Church === http://devblog.brahmancreations.com ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Is it possible to redefine FreePascal types?
On Wed, Nov 21, 2012 at 5:34 PM, Graeme Geldenhuys gra...@geldenhuys.co.ukwrote: That is an incorrect assumptions. The compiler will happily accept both types without needing typecasting. I stand corrected. I assumed it behaved the same as Delphi in this respect. It doesn't, not even when Delphi mode is enabled. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Access to compiler's internal data structures
My goal is to make it an IDE expert so the CodeTools parser sounds ideal. Just didn't want to reinvent the wheel. I also wanted to avoid the problem Delphi has been plagued with for years, that is, CodeInsight flagging code with syntax errors that the compiler readily accepts because they use different parsers. On Sep 1, 2012 3:54 AM, Bernd prof7...@gmail.com wrote: 2012/8/31 Kenneth Cochran kenneth.coch...@gmail.com: I'm finding myself in need of a parser for object pascal. I'm wondering if fpc exposes any of the output (syntax trees, graphs, etc) from the parser that could be consumed by an external tool? Depending on what exactly you need and how difficult it is to get a syntax tree from the compiler itself there exist at least two more parsers that *might* be useful for you: one of them is in the CodeTools package in Lazarus and is used for autocomplete, refactoring, etc and another totally separate parser is in the Jedi code formating package (also part of Lazarus) that is used for re-formatting the code of a single unit. These parsers were written with different goals in mind and for different purposes, so they work slightly different and provide different output, for example the jedi parser will only parse one unit (and is not very closely connected with the IDE and can probably easily be ripped out of it and be used in a separate project) while the codetools parsers are able to follow used units, include files, respect currently active defines, etc. but are deeply integrated into the IDE and probably also depending on many parts of he IDE. If the project you have in mind would be something that helps coding or understanding and analyzing existing code it might probably be very nice to have it available as a part of the Lazarus IDE (as an installable package) and let it extend the CodeTools parsers. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Access to compiler's internal data structures
First I'll say I know very little about the inner workings of an actual compiler. I took a course on formal language theory ages ago so I do have some understanding of the theory. Lately my interests have been pulling me toward projects that either benefit from or depend on static analysis. So I'm finding myself in need of a parser for object pascal. I'm wondering if fpc exposes any of the output (syntax trees, graphs, etc) from the parser that could be consumed by an external tool? ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
