Re: [fpc-pascal] GetTableNames in TSQLConnection / Postgresql
On Tue, 18 Dec 2012, John wrote: TSchemaOption = (soPrependSchemaName,soIncludeSystemObjects); TSchemaOptions = set of TSchemaOption; Procedure GetTableNames(List : TStrings; Options : TSchemaOptions = []); I am not interested in schema information, but I can imagine some people are (the original poster, obviously). The above caters for everyone and keeps backwards compatibility. A table name without a schema is useless, at least in Postgres, and, from memory, in Oracle. Most simply, two schemas foo1 and foo2 (in the same database) both can have a table jobs. If you log in as a user with access on both schemas, you cannot just ask for table 'jobs' without prefixing it. If you log in as the owner of foo1 and just ask for jobs, you MAY get it - I haven't checked - but if you log in as anyone else, you HAVE to prefix it with the schema - ie - select * from foo1.jobs - or the query will fail. This is true even if there is no duplication of table names. So if you want to use GetTableNames to get a list of tables, then try to use one - mostly you can't! That brings me back to the original point that either gettablenames has to operate on a known schema only (so you can supply the schema afterwards), or it has to supply the schema with the table name. I would opt for the latter, hence the soPrependSchemaName. The term Schema seems to be used in different ways in the code - I wonder if there is some confusion ? Maybe other databases use it in a different way ? MySQL, Firebird, MS-access, sqlite simply do not have schema as Oracle has. In PostGres or MS-SQL it's optional, to my knowledge (not an expert). I am using Firebird, so being forced to use schema would be a serious disadvantage. That said, I understand you need it, we're just trying to find a solution that is goodacceptable for everyone. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Documentation
On 18/12/12 01:25, luciano de souza wrote: But my question is: FPDoc can be used without an IDE? Yes, fpdoc is a command line tool, just the fpc (The free pascal compiler). Some get confused between the fpdoc program, and the FPDoc Editor (add-on) included within Lazarus IDE. The latter is used to edit the XML description files (documentation). If true, would I have to create the XML structure manually? I always write my XML description files with a text editor, simply because there exists no editor application that supports everything fpdoc syntax does. Also the fpdoc XML syntax is rather simple. I use MSEide as my editor of choice for documentation - due to much better code templates support. I have setup quite a few fpdoc code templates in MSEide, which speeds up my writing of fpdoc xml syntax. That way I can rather concentrate on writing the documentation and not the XML tags (or fighting with some documentation editor tool). Pasdoc is a very good tool, but that's true the source code becomes overcrowded. It is very clear that it is a personal preference. There is no right or wrong. Some like inline documentation, others like external documentation. I like complete and detailed documentation, not just one-liners. So External Documentation files is the only way for me, otherwise I will never be able to read my object pascal source code. Plus, using fpdoc, I can generate PDF, INF, CHM and HTML output from the same XML description files. 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] Re: Documentation
On 18-12-2012 0:58, Graeme Geldenhuys wrote: There are other issues with the FPDoc Editor dialog though. Off the top of my head: As I think I said last year, there's also Laz DE/Lazarus Documentation Editor. As long as we're suggesting improvements, I'd like LazDE to 1. show a formatted view of the resulting fpdoc (i.e. use fpdoc processing to output as e.g. HTML and show that) so you have direct feedback on how your documentation looks. 2. use an XML syntax highlighter (synmemo?) (if it's not already there). Helps with those missing closing tags etc I suffer from 3. allow drag and drop from an identifier in a source code window to create a link automatically. 4. (from memory, haven't done this a while) make it easier to start documenting a new unit. Whenever I start, I have no idea what package name I should supply. Some automated suggestions might be nice. However, fpdoc documentation writing is a huge chore for me compared to writing in the wiki so I've decided it's more productive to get my documentation done on the wiki. I still have documentation for the zip unit lying around and I'm trying to get that in shape to submit it. Meanwhile I've updated the fpdoc code some with cosmetic changes/better warning messages: http://bugs.freepascal.org/view.php?id=23506 ... so if anybody is interested ;) Thanks, Reinier ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Documentation
On Tue, 18 Dec 2012, Reinier Olislagers wrote: On 18-12-2012 0:58, Graeme Geldenhuys wrote: There are other issues with the FPDoc Editor dialog though. Off the top of my head: As I think I said last year, there's also Laz DE/Lazarus Documentation Editor. As long as we're suggesting improvements, I'd like LazDE to 1. show a formatted view of the resulting fpdoc (i.e. use fpdoc processing to output as e.g. HTML and show that) so you have direct feedback on how your documentation looks. 2. use an XML syntax highlighter (synmemo?) (if it's not already there). Helps with those missing closing tags etc I suffer from 3. allow drag and drop from an identifier in a source code window to create a link automatically. 4. (from memory, haven't done this a while) make it easier to start documenting a new unit. Whenever I start, I have no idea what package name I should supply. Some automated suggestions might be nice. However, fpdoc documentation writing is a huge chore for me compared to writing in the wiki so I've decided it's more productive to get my documentation done on the wiki. A wiki is never documentation. It's an explanation - at best. Usually (not targeting anyone here) it is sloppy, incomplete, not maintained, no verification of the up-to-dateness possible. It's some quick and dirty text which you jot down if and when you feel like it. Writing quality documentation IS a chore. There is no way around it. That is why companies have tech writers employed for this job. I still have documentation for the zip unit lying around and I'm trying to get that in shape to submit it. Meanwhile I've updated the fpdoc code some with cosmetic changes/better warning messages: http://bugs.freepascal.org/view.php?id=23506 ... so if anybody is interested ;) I applied the patch, thank you ! Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Documentation
On 18-12-2012 12:15, michael.vancann...@wisa.be wrote: On Tue, 18 Dec 2012, Reinier Olislagers wrote: However, fpdoc documentation writing is a huge chore for me compared to writing in the wiki so I've decided it's more productive to get my documentation done on the wiki. A wiki is never documentation. It's an explanation - at best. No, a wiki is a way to store articles/text that people can read. What is in those articles is up to what you put in it. Of course, a wiki has certain drawbacks - e.g. no structure and the ones you mention below. Remember paper documentation though? That has drawbacks, too, some of them similar to the wiki. Usually (not targeting anyone here) it is sloppy, incomplete, not maintained, no verification of the up-to-dateness possible. Mostly agreed. In the same spirit: how up to date, complete and actually helpful is the fpdoc documentation? As for up to dateness: there is a history on the wiki, so you can check that. Your idea of building a (web) interface that lets people easily update fpdoc documentation and submit the result for approval by a dev and subsequent implementation makes a lot of sense. Writing quality documentation IS a chore. There is no way around it. I agree but I was refering to the document format, not so much the content of the documentation. Having to fight with the fpdoc format where I get unhelpful help messages like Warning: Target ID of link in unit zipper is unknown: empty is a bit too much for me. So I put my stuff on the wiki because it's much quicker to write and update. http://bugs.freepascal.org/view.php?id=23506 ... so if anybody is interested ;) I applied the patch, thank you ! Thanks a lot. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Documentation
In our previous episode, Reinier Olislagers said: However, fpdoc documentation writing is a huge chore for me compared to writing in the wiki so I've decided it's more productive to get my documentation done on the wiki. Wiki is not versioned, not context sensitive etc. It is a perfect place to do some quick scribblings and howtos, but it is not a solution for final documentation. Yes, making documentation is tedious. No pain, no gain. I still have documentation for the zip unit lying around and I'm trying to get that in shape to submit it. Meanwhile I've updated the fpdoc code some with cosmetic changes/better warning messages: http://bugs.freepascal.org/view.php?id=23506 ... so if anybody is interested ;) I'm planning doing some fpdoc testing in the holidays. (partially also because I need to generate 2.6.2 CHMs) ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Documentation
On 18/12/12 11:15, michael.vancann...@wisa.be wrote: I applied the patch, thank you ! While we are at it, here is another patch for fpdoc - lying around for a while. http://bugs.freepascal.org/view.php?id=23425 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
Re: [fpc-pascal] Re: Documentation
On Tue, 18 Dec 2012, Graeme Geldenhuys wrote: On 18/12/12 11:15, michael.vancann...@wisa.be wrote: I applied the patch, thank you ! While we are at it, here is another patch for fpdoc - lying around for a while. http://bugs.freepascal.org/view.php?id=23425 Yes, I had looked at it, but didn't appply it. Done now, however. Thanks ! Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Documentation
In our previous episode, Graeme Geldenhuys said: I applied the patch, thank you ! While we are at it, here is another patch for fpdoc - lying around for a while. http://bugs.freepascal.org/view.php?id=23425 I also thought about that, but layouting the interface inheritance info is harder. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] GetTableNames in TSQLConnection / Postgresql
On 12/18/2012 07:35 PM, michael.vancann...@wisa.be wrote: snip MySQL, Firebird, MS-access, sqlite simply do not have schema as Oracle has. In PostGres or MS-SQL it's optional, to my knowledge (not an expert). For the record, in Postgres, it IS optional, in the sense that you can make all your tables in the public schema, in which case you don't need to specify the schema to access them, but if you make them in any other schema, you must specify it in the query. (And yes, I have only just found that out, by experiment. Coming from an Oracle background, I just always made schemas for my tables.) cheers, John Sunderland ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] GetTableNames in TSQLConnection / Postgresql
On Wed, 19 Dec 2012, John wrote: On 12/18/2012 07:35 PM, michael.vancann...@wisa.be wrote: snip MySQL, Firebird, MS-access, sqlite simply do not have schema as Oracle has. In PostGres or MS-SQL it's optional, to my knowledge (not an expert). For the record, in Postgres, it IS optional, in the sense that you can make all your tables in the public schema, in which case you don't need to specify the schema to access them, but if you make them in any other schema, you must specify it in the query. (And yes, I have only just found that out, by experiment. Coming from an Oracle background, I just always made schemas for my tables.) Confirming once again that we are all creatures of habit :-) I think that with the modifications proposed here, we should be able to cater for many habits :-) Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Documentation
On 18/12/12 13:28, Marco van de Voort wrote: I also thought about that, but layouting the interface inheritance info is harder. It works here for Interface inheritance too. But I didn't have much code to test it with. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ attachment: Untitled.png___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Submitted paszlib/zipper documentation fpdoc stripper questions
Hi all, Finally got my FPC zip/unzip unit documentation in shape and submitted it as 23508 [Patch] Zipper documentation A long time ago, I mistakenly generated an fpdoc skeleton with private members etc visible for that unit doc and started documenting. I wrote this program to get rid again of all comments and empty elements: https://bitbucket.org/reiniero/fpc_laz_patch_playground/downloads/fpdocstripper.zip Results snippets Before: !-- property Visibility: public -- element name=TUnZipper.Files shortFiles in zip file (deprecated)/short descrList of files that should be compressed in the zip file. Note: deprecated. Use Entries.AddFileEntry(FileName) or Entries.AddFileEntries(List) instead. /descr seealso/ /element !-- property Visibility: public -- element name=TUnZipper.Entries short/ descr/ seealso/ /element !-- class Visibility: default -- element name=EZipError shortException specific to the zipper unit/short /element /module !-- zipper -- /package /fpdoc-descriptions After: element name=TUnZipper.Files shortFiles in zip file (deprecated)/short descrList of files that should be compressed in the zip file. Note: deprecated. Use Entries.AddFileEntry(FileName) or Entries.AddFileEntries(List) instead. /descr /element element name=EZipError shortException specific to the zipper unit/short /element /module /package /fpdoc-descriptions Questions: 1. Is there perhaps an easier way of doing this, e.g. using the logic in existing fpdoc code? I've looked at it but in the end it seemed much quicker to use XML units directly 2. Please let me know suggestions for improvement... I'm not an XML guru and I'm afraid the code is not that good. Looking forward to learn from your comments. Thanks, Reinier ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Class procedural type
Once upon a time, on 12/18/2012 06:42 AM to be precise, Sven Barth said: Am 17.12.2012 22:27 schrieb Ewald ew...@yellowcouch.org mailto:ew...@yellowcouch.org: It should not contain this hidden parameter? In that case the above code (with the intermediate pointer cast) would prove correct? (of course it is no cross platform solution or anything, but that is besides the matter now) It would be a cross plattform solution, because the method pointer will just be a Pointer insteat of a TMethod record. Indeed, my thoughts got a bit mixed up at one point. This would indeed be cross platform. If you want to use the above you need to declare your method as static;. In that case a method will behave the same as a normal procedure variable, but if you want to change e.g. class properties or class variables of the class the method belongs to, you must use the class name (e.g. TMyClass.MyProperty) to access it. So if I get you right, the use of `static` after a method make the hidden class type parameter disappear, but also mandates use of the class name every time I want to use the class' [static fields / class properties / class methods]? Not quite, see Paul's mail. Sorry for the confusion :) Suppose TTestClass contains `AField: Integer; static;`, then the following would be right if I understand you correctly? Class Procedure TTestClass.AMethod; static; // I don't know if `static` should be in the implementation as well, but I'll soon figure out :-) It's enough to have it in the declaration. Alright. Seems like you helped me fix this issue. Thanks for your time (as well as Paul's of course)! -- Ewald ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re:[fpc-pascal] Bitpacked dynamic array support
Hi Flávio You can use sets or TBits. Unless you mean packed arrays of byte or word, etc. In this case you just declare myvar: packed array of byte. -Flávio I meant bitpacked arrays of boolean. That's when boolean occupies only one bit in memory. Yes, I can use TBits, but unfortunately for operation that I care about it's not an option. I attached the benchmark with numbers a sequential reading in a loop. All in all TBits performance is really low. Currently it's about 150 times lower than QWord reading (near optimal on my machine) Read from memory Array 100 elements Read Byte0.004380 sek Speed,MB/sec = 217.73 Read Word0.002950 sek Speed,MB/sec = 646.56 Read DWord 0.004550 sek Speed,MB/sec = 838.40 Read QWord 0.003943 sek Speed,MB/sec = 1934.92 Read bitpacked 0.002745 sek Speed,MB/sec =43.43 Read TBits 0.009329 sek Speed,MB/sec =12.78 (!!!) Test program attached. -- Regards, Denis Golovan testbits.tar.gz Description: GNU Zip compressed data ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Codetools and C-style constructs
Looking through some of the codetools sources makes me wonder if the codetools overlooks some C-style FPC operators. KeywordFuncLists.pas, for instance, seems not to know about , , +=, -=, *=, /=. Or are these operators are catered for elsewhere in the codetools? Howard ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Codetools and C-style constructs
On Tue, 18 Dec 2012 21:13:22 + Howard Page-Clark h...@talktalk.net wrote: Looking through some of the codetools sources makes me wonder if the codetools overlooks some C-style FPC operators. KeywordFuncLists.pas, for instance, seems not to know about , , +=, -=, *=, /=. I added the and . The others are assignment operators. AFAIK they can not be overloaded. Or are these operators are catered for elsewhere in the codetools? Can you give an example, in what context you are missing an operator? Mattias ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Codetools and C-style constructs
On 18/12/12 10:56, Mattias Gaertner wrote: Looking through some of the codetools sources makes me wonder if the codetools overlooks some C-style FPC operators. KeywordFuncLists.pas, for instance, seems not to know about , , +=, -=, *=, /=. I added the and . The others are assignment operators. AFAIK they can not be overloaded. Or are these operators are catered for elsewhere in the codetools? Can you give an example, in what context you are missing an operator? I have not encountered any errors in relation to codetoools handling of these operators, and I had not understood the overload orientation of the routines in that unit. I'm just trying to fathom how some of the functionality works (from browsing the source), piece by piece. Howard ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
