Re: [fpc-pascal] GetTableNames in TSQLConnection / Postgresql
I think, that if this view(s) is(are) presented in all versions of
PostgreSQL which fcl-db is going to support, that it is no problem
use them
(I must note, that my preffered way is follow sql standard
INFORMATION_SCHEMA views at least in column naming)
The equivalent INFORMATION_SCHEMA view is tables, but it does not
provide any easy way of distinguishing user tables from system tables.
*yes
*
It appears to me that it would be necessary to link back to
schemata and only select those schemas that were/were not owned by
postgres. (Of course, this would be OK if we were only selecting for
a particular schema.) If we were putting the code into
TSQLConnection, it would be worth the pain to use the standard
INFORMATION_SCHEMA views, I guess, but if it is done separately for
each db connection, it seems it is just as easy - and probably more
reliable - to use the postgres view where all is done for us.
*in principle I am not against it. Let's use DB specific views if they
are there, but use COLUMN NAMING compatible with sql standard
(like Reinier mentioned here:
http://wiki.lazarus.freepascal.org/Database_metadata#Proposal_for_extension.2Funiformization
)
*
2) The simple way to get the schemas would be to simply 'select ...
schemaname||'.'||relname as table_name ... from
pg_stat_user_tables. This would be a change ONLY to the sql in
pqconnection. (If worst comes to worst, I dare say could create my
own pqconnection derivative with this change.)
Hm, if you want get also schema_name then you should use this approach:
sqlquery1.SchemaType:=stTables;
sqlquery1.Open;
and in loop fill TStrings using
sqlquery1.FieldByName('schema_name')+'.'+sqlquery1.FieldByName('table_name')
At present, the schema isn't read into the query (so we have to change
the db connection), and the above code would have to be put into
TSQLConnecion, where (1) it would only apply to stTables, and (2)
would not work if any database species did not return the schema.
Probably to do this it would be necessary to be able to select
multiple fields in the AReturnField of GetDBInfo, all of which would
be far more complicated than what I suggested as a simple solution!
*Yes it will be more complicated.
I did short comparasion in Delphi and in case of BDE table names are
returned as schema.table in case of ADO,DBX only table without
schema is returned. So again inconsistency between various DB client
technologies.
If others agree, IMO we can do it like this:
1. use PG specific system view query, where we add SCHEMA_TABLE_NAME
column (other columns like SCHEMA_NAME, TABLE_NAME, TABLE_TYPE etc
remains) which will be as you suggested: schemaname||'.'||relname
2. override for TPQConnection.GetTableNames:
GetDBInfo(stTables,'','SCHEMA_TABLE_NAME',List)
-Laco.
*
(This is before we start on the argument about whether it is better to
return multiple fields and concatenate them in the client, or select
the concatenated fields on the server in the first place, which I
think is quite debatable.)
3) A better solution, in my opinion, would be to add some extra
TSchemaTypes, with matching TSQLConnection calls, for GetSchemas,
GetTablesInSchema, and possibly the TableBySchema option as in
(2). It seems the infrastructure already exists to do all of
these things.
Personally I am not fan of this approach (mainly, because of keeping
Delphi compatibility).
So how does Delphi do it ? I can't imagine it returns all the table
names with no schema specified (as a filter) or prepended. It is a
long time since I used Delphi against a real database (Delphi 4 C/S
against Oracle) but I can't remember any of these problems. I have no
argument with matching Delphi behaviour if it is feasible, but by the
same token I don't see adding behaviour is a problem as long as
existing behaviour is not broken.
-Laco.
@Reinier:
Analysis:
As far as I can work out, a call to GetTableNames calls GetDBInfo, with
parameters
ASchemaType : TSchemaType - This specifies what info we want - user
tables, sys tables, procedures, columns etc
ASchemaObjectName - Doesn't seem to be used, it is specified as
No, it's not used for GetTableNames; it is used e.g. to specify the
table name if you want to know info about columns.
Yes, I saw that, but there seems no reason why it could not be used as
a schema selection.
I also had a flip through the previous discussion, but it was indeed a
long and tortuous thread to follow!
So the question comes back to how should the table names be returned
? Indeed, is there a specification for what should be returned for
all of these metadata queries ?
cheers,
John Sunderland
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
[fpc-pascal] Re: Indexing files
On 16-12-2012 20:40, Krzysztof wrote: And which database you prefer? I don't need complicated functionality. The most important is insert speed and it must be embedded. I'm thinking of SQLight, DBF or Firebird Embedded I'd probably go with SQLite or Firebird embedded. SQlite is probably a bit easier to deploy and e.g. available on OSX by default anyway... however, I like Firebird's features and the fact that you can change to a client/server setup without changing code. So it depends on your requirements. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] GetTableNames in TSQLConnection / Postgresql
Reinier Olislagers wrote / napísal(a): On 16-12-2012 2:27, John wrote: @Reinier: Analysis: As far as I can work out, a call to GetTableNames calls GetDBInfo, with parameters ASchemaType : TSchemaType - This specifies what info we want - user tables, sys tables, procedures, columns etc ASchemaObjectName - Doesn't seem to be used, it is specified as No, it's not used for GetTableNames; it is used e.g. to specify the table name if you want to know info about columns. Yes, I saw that, but there seems no reason why it could not be used as a schema selection. I understand; just wanted to let you know what it was used for. I also had a flip through the previous discussion, but it was indeed a long and tortuous thread to follow! Agreed. AFAIR, there was a decision in the end... but it was a long thread and a long while ago. I've incorporated some of Lacak's proposal into http://wiki.lazarus.freepascal.org/Database_metadata#Proposal_for_extension.2Funiformization ... and will update that page going through that thread. Good job! Thanks. -Laco. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] GetTableNames in TSQLConnection / Postgresql
On Mon, 17 Dec 2012, LacaK wrote:
2) The simple way to get the schemas would be to simply 'select ...
schemaname||'.'||relname as table_name ... from pg_stat_user_tables.
This would be a change ONLY to the sql in pqconnection. (If worst comes
to worst, I dare say could create my own pqconnection derivative with
this change.)
Hm, if you want get also schema_name then you should use this approach:
sqlquery1.SchemaType:=stTables;
sqlquery1.Open;
and in loop fill TStrings using
sqlquery1.FieldByName('schema_name')+'.'+sqlquery1.FieldByName('table_name')
At present, the schema isn't read into the query (so we have to change the
db connection), and the above code would have to be put into TSQLConnecion,
where (1) it would only apply to stTables, and (2) would not work if any
database species did not return the schema. Probably to do this it would
be necessary to be able to select multiple fields in the AReturnField of
GetDBInfo, all of which would be far more complicated than what I suggested
as a simple solution!
*Yes it will be more complicated.
I did short comparasion in Delphi and in case of BDE table names are returned
as schema.table in case of ADO,DBX only table without schema is returned.
So again inconsistency between various DB client technologies.
IMHO all the more reason to use 2 different fields, and keep table in 1 field.
If others agree, IMO we can do it like this:
1. use PG specific system view query, where we add SCHEMA_TABLE_NAME column
(other columns like SCHEMA_NAME, TABLE_NAME, TABLE_TYPE etc remains) which
will be as you suggested: schemaname||'.'||relname
I would use 2 separate fields. This way the table field always only contains
the table. People interested in the schema, can read the schema field.
It's easier to concatenate 2 fields than to separate out 2 parts of a field,
doubly so if you don't know whether the 2 parts are there or not.
Michael.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Brook 1.0 - A new framework for web was born
On Sun, 16 Dec 2012, Graeme Geldenhuys wrote: On 15/12/2012 21:22, Sven Barth wrote: Maybe because the authors prefered inline comments instead of fpdoc's XML files... A shame, because the more detailed the documentation, the more it obfuscates the code. eg: Documentation Insight, a popular Delphi IDE plugin for documenting frameworks from inside the IDE's most requested feature... external documentation files because good documentation means lots of text and examples, thus lots and lots of code obfuscation. Exactly the reason why fpdoc uses external XML. A pasdoc-to-fpdoc conversion is on my TODO list. (tracker item 325689871 ;)) Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] GetTableNames in TSQLConnection / Postgresql
michael.vancann...@wisa.be wrote / napísal(a):
On Mon, 17 Dec 2012, LacaK wrote:
2) The simple way to get the schemas would be to simply 'select
... schemaname||'.'||relname as table_name ... from
pg_stat_user_tables. This would be a change ONLY to the sql in
pqconnection. (If worst comes to worst, I dare say could create
my own pqconnection derivative with this change.)
Hm, if you want get also schema_name then you should use this
approach:
sqlquery1.SchemaType:=stTables;
sqlquery1.Open;
and in loop fill TStrings using
sqlquery1.FieldByName('schema_name')+'.'+sqlquery1.FieldByName('table_name')
At present, the schema isn't read into the query (so we have to
change the db connection), and the above code would have to be put
into TSQLConnecion, where (1) it would only apply to stTables, and
(2) would not work if any database species did not return the
schema. Probably to do this it would be necessary to be able to
select multiple fields in the AReturnField of GetDBInfo, all of
which would be far more complicated than what I suggested as a
simple solution!
*Yes it will be more complicated.
I did short comparasion in Delphi and in case of BDE table names are
returned as schema.table in case of ADO,DBX only table without
schema is returned. So again inconsistency between various DB client
technologies.
IMHO all the more reason to use 2 different fields, and keep table in
1 field.
If others agree, IMO we can do it like this:
1. use PG specific system view query, where we add SCHEMA_TABLE_NAME
column (other columns like SCHEMA_NAME, TABLE_NAME, TABLE_TYPE etc
remains) which will be as you suggested: schemaname||'.'||relname
I would use 2 separate fields. This way the table field always only
contains
the table. People interested in the schema, can read the schema field.
Yes. May be, that I was not clear. My suggestion was 3+ fields in query:
SCHEMA_NAME, TABLE_NAME, SCHEMA_TABLE_NAME (SCHEMA_NAME || '.' ||
TABLE_NAME)
But original question AFAIU was about: what should GetTableNames return
(schema query can return multiple columns, but what column use when fill
list of table names)?
GetTableNames return list of table names into TStrings.
Now only TABLE_NAME is returned. John requested, that also schema name
should be prefixed (if there is any)
-Laco.
It's easier to concatenate 2 fields than to separate out 2 parts of a
field,
doubly so if you don't know whether the 2 parts are there or not.
Michael.
___
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] GetTableNames in TSQLConnection / Postgresql
On Mon, 17 Dec 2012, LacaK wrote:
michael.vancann...@wisa.be wrote / napísal(a):
On Mon, 17 Dec 2012, LacaK wrote:
2) The simple way to get the schemas would be to simply 'select ...
schemaname||'.'||relname as table_name ... from pg_stat_user_tables.
This would be a change ONLY to the sql in pqconnection. (If worst
comes to worst, I dare say could create my own pqconnection derivative
with this change.)
Hm, if you want get also schema_name then you should use this approach:
sqlquery1.SchemaType:=stTables;
sqlquery1.Open;
and in loop fill TStrings using
sqlquery1.FieldByName('schema_name')+'.'+sqlquery1.FieldByName('table_name')
At present, the schema isn't read into the query (so we have to change
the db connection), and the above code would have to be put into
TSQLConnecion, where (1) it would only apply to stTables, and (2) would
not work if any database species did not return the schema. Probably to
do this it would be necessary to be able to select multiple fields in the
AReturnField of GetDBInfo, all of which would be far more complicated
than what I suggested as a simple solution!
*Yes it will be more complicated.
I did short comparasion in Delphi and in case of BDE table names are
returned as schema.table in case of ADO,DBX only table without schema
is returned. So again inconsistency between various DB client
technologies.
IMHO all the more reason to use 2 different fields, and keep table in 1
field.
If others agree, IMO we can do it like this:
1. use PG specific system view query, where we add SCHEMA_TABLE_NAME
column (other columns like SCHEMA_NAME, TABLE_NAME, TABLE_TYPE etc
remains) which will be as you suggested: schemaname||'.'||relname
I would use 2 separate fields. This way the table field always only
contains
the table. People interested in the schema, can read the schema field.
Yes. May be, that I was not clear. My suggestion was 3+ fields in query:
SCHEMA_NAME, TABLE_NAME, SCHEMA_TABLE_NAME (SCHEMA_NAME || '.' || TABLE_NAME)
But original question AFAIU was about: what should GetTableNames return
(schema query can return multiple columns, but what column use when fill list
of table names)?
GetTableNames return list of table names into TStrings.
Now only TABLE_NAME is returned. John requested, that also schema name should
be prefixed (if there is any)
Ah, that was not clear to me :-)
But why the SCHEMA_TABLE_NAME ? It's redundant information, as the
information is present in SCHEMA_NAME and TABLE_NAME anyway ?
If you need the schema name, why not just access the SCHEMA_NAME field ?
A different story is the GetTableNames call, which will - presumably - use
the above information.
There I think some extra options are needed:
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.
Michael.___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] GetTableNames in TSQLConnection / Postgresql
michael.vancann...@wisa.be wrote / napísal(a):
On Mon, 17 Dec 2012, LacaK wrote:
michael.vancann...@wisa.be wrote / napísal(a):
On Mon, 17 Dec 2012, LacaK wrote:
2) The simple way to get the schemas would be to simply 'select
... schemaname||'.'||relname as table_name ... from
pg_stat_user_tables. This would be a change ONLY to the sql in
pqconnection. (If worst comes to worst, I dare say could create
my own pqconnection derivative with this change.)
Hm, if you want get also schema_name then you should use this
approach:
sqlquery1.SchemaType:=stTables;
sqlquery1.Open;
and in loop fill TStrings using
sqlquery1.FieldByName('schema_name')+'.'+sqlquery1.FieldByName('table_name')
At present, the schema isn't read into the query (so we have to
change the db connection), and the above code would have to be put
into TSQLConnecion, where (1) it would only apply to stTables, and
(2) would not work if any database species did not return the
schema. Probably to do this it would be necessary to be able to
select multiple fields in the AReturnField of GetDBInfo, all of
which would be far more complicated than what I suggested as a
simple solution!
*Yes it will be more complicated.
I did short comparasion in Delphi and in case of BDE table names
are returned as schema.table in case of ADO,DBX only table
without schema is returned. So again inconsistency between various
DB client technologies.
IMHO all the more reason to use 2 different fields, and keep table
in 1 field.
If others agree, IMO we can do it like this:
1. use PG specific system view query, where we add
SCHEMA_TABLE_NAME column (other columns like SCHEMA_NAME,
TABLE_NAME, TABLE_TYPE etc remains) which will be as you suggested:
schemaname||'.'||relname
I would use 2 separate fields. This way the table field always only
contains
the table. People interested in the schema, can read the schema field.
Yes. May be, that I was not clear. My suggestion was 3+ fields in query:
SCHEMA_NAME, TABLE_NAME, SCHEMA_TABLE_NAME (SCHEMA_NAME || '.' ||
TABLE_NAME)
But original question AFAIU was about: what should GetTableNames
return (schema query can return multiple columns, but what column use
when fill list of table names)?
GetTableNames return list of table names into TStrings.
Now only TABLE_NAME is returned. John requested, that also schema
name should be prefixed (if there is any)
Ah, that was not clear to me :-)
But why the SCHEMA_TABLE_NAME ? It's redundant information, as the
information is present in SCHEMA_NAME and TABLE_NAME anyway ?
*Yes is redundant
*
If you need the schema name, why not just access the SCHEMA_NAME field ?
*SCHEMA_TABLE_NAME only as helper for GetDBInfo (look how is implemented
;-))
*
A different story is the GetTableNames call, which will - presumably -
use
the above information.
*Yes it is point of story ... GetTableNames call GetDBInfo which calls
SetSchemaInfo and in loop fills TStrings with provided AReturnField Field.
*
There I think some extra options are needed:
TSchemaOption = (soPrependSchemaName,soIncludeSystemObjects);
TSchemaOptions = set of TSchemaOption;
Procedure GetTableNames(List : TStrings; Options : TSchemaOptions = []);
*possible, but introduces incompatibility with Delphi, where
GetTableNames is declared like now in FPC (GetTableNames(List: TStrings;
SystemTables: Boolean) + other overloads)
So SystemTables is there already ...
*
I am not interested in schema information,
*ok, then we can leave things as are now and do only:
1. update PG GetSchemaInfoSQL to correctly fill schema_name (now it is
always blank)
2. users who are interested in schema name must use instead of
GetTableNames own but simple loop:
* sqlquery1.SchemaType:=stTables;
sqlquery1.Open;
while not sqlquery1.Eof do begin
List.Items.Append(sqlquery1.FieldByName('schema_name')+'.'+sqlquery1.FieldByName('table_name'));
sqlquery1.next;
end;
*-Laco.*
but I can imagine some people are
(the original poster, obviously). The above caters for everyone and keeps
backwards compatibility.
Michael.
___
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] GetTableNames in TSQLConnection / Postgresql
On Mon, 17 Dec 2012, LacaK wrote: But original question AFAIU was about: what should GetTableNames return (schema query can return multiple columns, but what column use when fill list of table names)? GetTableNames return list of table names into TStrings. Now only TABLE_NAME is returned. John requested, that also schema name should be prefixed (if there is any) Ah, that was not clear to me :-) But why the SCHEMA_TABLE_NAME ? It's redundant information, as the information is present in SCHEMA_NAME and TABLE_NAME anyway ? *Yes is redundant Redundancy is bad in data :) A different story is the GetTableNames call, which will - presumably - use the above information. *Yes it is point of story ... GetTableNames call GetDBInfo which calls SetSchemaInfo and in loop fills TStrings with provided AReturnField Field. * There I think some extra options are needed: TSchemaOption = (soPrependSchemaName,soIncludeSystemObjects); TSchemaOptions = set of TSchemaOption; Procedure GetTableNames(List : TStrings; Options : TSchemaOptions = []); *possible, but introduces incompatibility with Delphi, where GetTableNames is declared like now in FPC (GetTableNames(List: TStrings; SystemTables: Boolean) + other overloads) So SystemTables is there already ... There is no need for incompatibility ? We keep the call as it exists now, and redirect it to the new call with the extended options. We do this in several places in the RTL/FCL already. The idea is to offer more options, this way there is no need for custom solutions. Everyone benefits. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] GetTableNames in TSQLConnection / Postgresql
On 17/12/2012 10:45, michael.vancann...@wisa.be wrote: On Mon, 17 Dec 2012, LacaK wrote: Yes. May be, that I was not clear. My suggestion was 3+ fields in query: SCHEMA_NAME, TABLE_NAME, SCHEMA_TABLE_NAME (SCHEMA_NAME || '.' || TABLE_NAME) But original question AFAIU was about: what should GetTableNames return (schema query can return multiple columns, but what column use when fill list of table names)? GetTableNames return list of table names into TStrings. Now only TABLE_NAME is returned. John requested, that also schema name should be prefixed (if there is any) Ah, that was not clear to me :-) But why the SCHEMA_TABLE_NAME ? It's redundant information, as the information is present in SCHEMA_NAME and TABLE_NAME anyway ? If you need the schema name, why not just access the SCHEMA_NAME field ? A different story is the GetTableNames call, which will - presumably - use the above information. There I think some extra options are needed: 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. The question is also why return SCHEMA_NAME || '.' || TABLE_NAME when this is not always usable in a query later on ? One DB needs SCHEMA_NAME.TABLE_NAME, another `SCHEMA_NAME`.`TABLE_NAME`. An additional option soQuoteNames? Ludo ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Websocket client
But then you did not mention that you're looking for something cross-platform either.. ;-) Actually I did :P ...client which work on linux and windows ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] GetTableNames in TSQLConnection / Postgresql
On Mon, 17 Dec 2012, Ludo Brands wrote: On 17/12/2012 10:45, michael.vancann...@wisa.be wrote: On Mon, 17 Dec 2012, LacaK wrote: Yes. May be, that I was not clear. My suggestion was 3+ fields in query: SCHEMA_NAME, TABLE_NAME, SCHEMA_TABLE_NAME (SCHEMA_NAME || '.' || TABLE_NAME) But original question AFAIU was about: what should GetTableNames return (schema query can return multiple columns, but what column use when fill list of table names)? GetTableNames return list of table names into TStrings. Now only TABLE_NAME is returned. John requested, that also schema name should be prefixed (if there is any) Ah, that was not clear to me :-) But why the SCHEMA_TABLE_NAME ? It's redundant information, as the information is present in SCHEMA_NAME and TABLE_NAME anyway ? If you need the schema name, why not just access the SCHEMA_NAME field ? A different story is the GetTableNames call, which will - presumably - use the above information. There I think some extra options are needed: 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. The question is also why return SCHEMA_NAME || '.' || TABLE_NAME when this is not always usable in a query later on ? One DB needs SCHEMA_NAME.TABLE_NAME, another `SCHEMA_NAME`.`TABLE_NAME`. An additional option soQuoteNames? Well, if you don't need the concatenation, presumably you don't need the quotes :-) I thought the schema query is connection dependent ? In that case, there is no need for this option, as the connection will apply the quotes as needed ? Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Websocket client
Ok finally I get working demo of first websocket client based on synapse: http://code.google.com/p/bauglir-websocket . If you want to connect to test serwer on http://www.websocket.org you must set host exactly to ' echo.websocket.org' (don't use 'ws://' or 'http://' prefix!) and port to 80. But if someone know another clients, please share with it ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Brook 1.0 - A new framework for web was born
michael.vancann...@wisa.be wrote: On Sun, 16 Dec 2012, Graeme Geldenhuys wrote: On 15/12/2012 21:22, Sven Barth wrote: Maybe because the authors prefered inline comments instead of fpdoc's XML files... A shame, because the more detailed the documentation, the more it obfuscates the code. eg: Documentation Insight, a popular Delphi IDE plugin for documenting frameworks from inside the IDE's most requested feature... external documentation files because good documentation means lots of text and examples, thus lots and lots of code obfuscation. Exactly the reason why fpdoc uses external XML. A pasdoc-to-fpdoc conversion is on my TODO list. (tracker item 325689871 ;)) (We're getting off-topic from Brook, sorry...) A couple of answers (from the position of both PasDoc user and developer): 1. Although I personally prefer pasdoc, I was also thinking about implementing pasdoc output that produces fpdoc-compatible XML. This is quite easy to do in pasdoc (e.g. see our existing simplexml output), so if you want to do it this way, patches are surely welcome :) I wrote about it on http://pasdoc.sipsolutions.net/MichalisKamburelis#Fpdoc_output . 2. As for the discussion about whether it's better to have docs inside comments or as a separate files: 2.1. For what it's worth, you can place descriptions in separate files and still use PasDoc, see http://pasdoc.sipsolutions.net/ReadDescriptionFromFile . Whether this format is cleaner or not than fpdoc's XML file is up to the debate, anyway you *can* use separate files for the documentation. We also have features like introduction/conclusion where you write completely separate pages using pasdoc markup. 2.2. As for whether it's better to place documentation in comments or in separate files, I wrote about this on http://pasdoc.sipsolutions.net/MichalisKamburelis#Should_documentation_be_placed_inside_units_interface.2C_or_in_separate_files_.3F . And I still believe that generally the answer is it is a matter of taste. It comes down to the fact that I don't mind having a large unit interface with long comments inside. I don't see this as code obfuscation, I see my comments and examples as crucial and useful information that I want to keep together with the interface. You no longer can easily see the list of all your methods at a glance, but you can see them in the pasdoc output, so no loss. And the big advantage of keeping documentation inside source code is that it makes documentation easier to keep synchronized with code. Patches to the source code often naturally contain also changes to the related documentation in the interface. This keeps docs very up-to-date in my experience, which also means complete. YMMV of course, but I definitely know examples of PasDoc-produced documentation where it's very complete and useful. With documentation in a separate file, there is a risk that you will see writing documentation as a separate task, where you need to go edit these other files. In such case, chances of getting contributions that update both the source *and* the relevant documentation are much lower, at least in my experience. One practical note is also that documentation in source code approach is used by many tools in a lot of other languages too: Doxygen, OcamlDoc, JavaDoc, PhpDoc... Languages like Python and Lisp even recommend to place docs inside special strings in code (not just comments). So, somehow this approach can work Ok :) Michalis ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Re: Feature announcement: Generic type constraints
Ehm... you know that AFAIK all those languages have constraints as well? :) Yes, I do ;) Though if your comment is regarding the possible future developments: of course :D You got my point -- View this message in context: http://free-pascal-general.1045716.n5.nabble.com/Feature-announcement-Generic-type-constraints-tp5712290p5712325.html Sent from the Free Pascal - General mailing list archive at Nabble.com. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Indexing files
These calls are available in the linux unit. I have an article that describes how it works, if you want. @Michael Van Canneyt: Could you send mi link to this article? ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] GetTableNames in TSQLConnection / Postgresql
The question is also why return SCHEMA_NAME || '.' || TABLE_NAME when this is not always usable in a query later on ? One DB needs SCHEMA_NAME.TABLE_NAME, another `SCHEMA_NAME`.`TABLE_NAME`. An additional option soQuoteNames? Well, if you don't need the concatenation, presumably you don't need the quotes :-) I thought the schema query is connection dependent ? In that case, there is no need for this option, as the connection will apply the quotes as needed ? I'm not talking about the query to get the schema/table names but the result from GetTableNames. For those that want the schema information (reason for the soPrependSchemaName option) and want to write a query using a string from the result from GetTableNames are in for some parsing to quote the different parts. Reason why I suggested an additional option to quote the result from GetTableNames so that that can be handled by the connection. Ludo ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] GetTableNames in TSQLConnection / Postgresql
For now I added in rev.23163 schema name into query for PostgreSQL (so no empty schema name is returned, but valid schema name) Here I understand: stTables - list of all tables, which may include system tables (it is not clear from documentation)? stSysTables - list of ONLY system tables (not views) http://docwiki.embarcadero.com/Libraries/XE2/en/Data.SqlExpr.TSQLConnection.GetTableNames If SystemTables is true, only the system tables are added to List. If SystemTables is false, the list is filled with any tables that match the criteria specified by the TableScope http://docwiki.embarcadero.com/Libraries/XE2/en/Data.SqlExpr.TSQLConnection.TableScope property http://docwiki.embarcadero.com/Libraries/XE2/en/Data.SqlExpr.TCustomSQLDataSet.SetSchemaInfo stTables - Information about all the data tables on the database server that match the criteria specified by the SQL connection's TableScope http://docwiki.embarcadero.com/Libraries/XE2/en/Data.SqlExpr.TSQLConnection.TableScope property. stSysTables - Information about all of the system tables on the database server If an application calls GetTablesNames with SystemTables set to true, or calls SetSchemaInfo http://docwiki.embarcadero.com/Libraries/XE2/en/Data.SqlExpr.TCustomSQLDataSet.SetSchemaInfo with SchemaType set to stSysTables, system tables, and only system tables are returned, regardless of the value of *TableScope*. -Laco. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Class procedural type
Hello, Is there any way to define the appropriate type for `AMethod` (in mode ObjFPC)? TTestClass = Class Public Class Procedure AMethod; End; I tried Type TSomeType = Class Procedure; But this didn't work. Rather obvious of course since this could also be interpreted as a class named `Procedure` [I think]. Also I tried Type TSomeType = Class Procedure of Object; But this didn't get me any further. I read the manual (section 3.6 -- http://www.freepascal.org/docs-html/ref/refse17.html) and it contains no data in respect to this little problem of mine. Any ideas? BTW: For time being I fixed it through TProcType(Pointer(@TTestClass.AMethod)), where `TProcType = Procedure;`. I think this boiles down to the same as a class procedure is nothing more than a normal procedure as I see it (except for the name and some other syntax) -- Ewald ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Allegro.pas 4.4.4 released
Hello fellow Pascaloids, I'm proud to announce that Allegro.pas 4.4.4 was released some days ago. This new version has a lot of improvements: * Added full support for 64bit systems. * New API for data types, parameters and return values, less confusing that previous one. * Demonstration game improved, so now it's really re-usable, easer to adapt it to your own projects. * Two new add-ons including one to load OGG/Vorbis sound files (Credits to RPG Hacker for this [http://www.rpg-hacker.de/]). * A lot of bugfixing and document improvements. * A bunch of new examples and improvement of some of the old ones, so now it should be easer to understand how to do what you want to do. You can read the more complete CHANGE log, and, of course, download the last version and test it from SourceForge (http://allegro-pas.sourceforge.net/). Also I've upgraded the on-line documentation to the latest version. Next step is to upgrade the website, starting to the new SourceForge Project Management software, as well as to upload the new design done by Paco. Then I can follow with Allegro.pas 5. Guillermo Ñuño Martínez. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] How do FreePascal implement hardware exceptions handling?
2012/12/16 Sven Barth pascaldra...@googlemail.com Why are you doing this? install_exception_handlers is called during process entry of Win32/Win64 programs already, so calling this twice can be considered a bad(TM) idea. Regards, Maybe hence problems. I want to create own compiler for simplified language with exceptions. I analyze exceptions handling by copying fpc_NNN and setJmp routines to Delphi. Regards,Andrzej ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Documentation
Hi, as the question whether inline or external source docs are the way to go (again?) came up, here are my thoughts (currently searching for the best solution :) ): I personally prefer external docs (and thus started to use fpdoc); reasons are uncluttered source, less scrolling and (if you strictly limit oneself to 80 chars per line) readability on small screens (mobile). At the same time, I use short single (!) line comments to functions, very much the way pasdoc would use them. For sources in an early state (moving code around etc.) external documentation is really annoying, for the detailed documentation of mature source inline docs are simply unsuitable IMHO. Therefore I would really like to see a feature that combines both approaches, small inline comments, e.g. for IDE tooltips and overview documentation together with the possibility to have more detailed infos in external files. Don't get me wrong, that's not an complaint... ... I don't how much work it would be to extend fpdoc, but I really would like to contribute if I knew where to start [and had some more time...] :) Btw. I really like the lazarus fpdoc GUI... Just my 2 cents, d.l.i.w ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Websocket client
At 02:25 AM 12/17/2012, Krzysztof wrote: But then you did not mention that you're looking for something cross-platform either.. ;-) Actually I did :P ...client which work on linux and windows Sorry, my bad :-[ , I totally missed that, saw it now when I checked back at your original message... :-! Ralf ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Documentation
On Mon, 17 Dec 2012, dev.d...@gmail.com wrote: Hi, as the question whether inline or external source docs are the way to go (again?) came up, here are my thoughts (currently searching for the best solution :) ): I personally prefer external docs (and thus started to use fpdoc); reasons are uncluttered source, less scrolling and (if you strictly limit oneself to 80 chars per line) readability on small screens (mobile). At the same time, I use short single (!) line comments to functions, very much the way pasdoc would use them. For sources in an early state (moving code around etc.) external documentation is really annoying, for the detailed documentation of mature source inline docs are simply unsuitable IMHO. Well, I have planned a inline-to-external conversion for fpdoc for exactly this reason. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Class procedural type
On 17.12.2012 17:39, Ewald wrote: Hello, Is there any way to define the appropriate type for `AMethod` (in mode ObjFPC)? TTestClass = Class Public Class Procedure AMethod; End; I tried Type TSomeType = Class Procedure; But this didn't work. Rather obvious of course since this could also be interpreted as a class named `Procedure` [I think]. Also I tried Type TSomeType = Class Procedure of Object; But this didn't get me any further. I read the manual (section 3.6 -- http://www.freepascal.org/docs-html/ref/refse17.html) and it contains no data in respect to this little problem of mine. There is no real solution for this. Any ideas? BTW: For time being I fixed it through TProcType(Pointer(@TTestClass.AMethod)), where `TProcType = Procedure;`. I think this boiles down to the same as a class procedure is nothing more than a normal procedure as I see it (except for the name and some other syntax) This is not correct. A class method without static still has a hidden parameter through which the class type is passed. 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. Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Bitpacked dynamic array support
Hi guys It looks like currently FPC does not support dynamic bitpacked arrays. I wonder how much work it will take to make support for it? For some things, it's a really useful functionality. -- Regards, Denis Golovan ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Bitpacked dynamic array support
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 On Mon, Dec 17, 2012 at 5:46 PM, denisgolovan denisgolo...@yandex.ru wrote: Hi guys It looks like currently FPC does not support dynamic bitpacked arrays. I wonder how much work it will take to make support for it? For some things, it's a really useful functionality. -- Regards, Denis Golovan ___ 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] Documentation
On 17/12/12 17:57, dev.d...@gmail.com wrote: Btw. I really like the lazarus fpdoc GUI... Compared to Documentation Insight (a Delphi IDE add-on), the UI of FPDoc Editor has a lot to be desired for. Plus the fact that FPDoc Editor generates undesired formatted XML for fpdoc is not so nice. This makes me not use FPDoc Editor in Lazarus - which is unfortunate. But the idea of FPDoc Editor (tied into Lazarus IDE and working with the code editor) is great. It just needs some more polish. 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] Class procedural type
On 17 Dec 2012, at 20:04, Sven Barth wrote: There is no real solution for this. I already thought so, I thank you for clearing this matter up to me. Any ideas? BTW: For time being I fixed it through TProcType(Pointer(@TTestClass.AMethod)), where `TProcType = Procedure;`. I think this boiles down to the same as a class procedure is nothing more than a normal procedure as I see it (except for the name and some other syntax) This is not correct. A class method without static still has a hidden parameter through which the class type is passed. Ah, this is interesting. I didn't know of this hidden parameter, but now that you mention it, it makes sense. So if I declare the method as Class Procedure AMethod; static; 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) 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]? 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 :-) Begin AField:= 0; //Wrong? My guess is it would fail to compile in this case, but I haven't got a compiler at hand now. TTestClass.AField:= 0; //Right? End; Sorry if I've just written the same thing twice (maybe thrice ;-) ) , but I've got this feeling that this isn't anywhere in the manual pages so I want to be absolutely sure about this. -- Ewald ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Documentation
On Mon, 17 Dec 2012 20:44:08 + Graeme Geldenhuys gra...@geldenhuys.co.uk wrote: On 17/12/12 17:57, dev.d...@gmail.com wrote: Btw. I really like the lazarus fpdoc GUI... Compared to Documentation Insight (a Delphi IDE add-on), the UI of FPDoc Editor has a lot to be desired for. Plus the fact that FPDoc Editor generates undesired formatted XML for fpdoc is not so nice. I thought that was fixed? This makes me not use FPDoc Editor in Lazarus - which is unfortunate. But the idea of FPDoc Editor (tied into Lazarus IDE and working with the code editor) is great. It just needs some more polish. Mattias ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Class procedural type
18.12.12, 5:26, Ewald пишет: 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 :-) Begin AField:= 0; //Wrong? My guess is it would fail to compile in this case, but I haven't got a compiler at hand now. TTestClass.AField:= 0; //Right? End; Both calls will work. AMethod still belongs to class, so it first searches identifier in that class. Best regards, Paul Ishenin ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Documentation
On 17/12/12 21:45, Mattias Gaertner wrote: I thought that was fixed? Umm, I'll have to double check. 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] Documentation
On 17/12/12 21:45, Mattias Gaertner wrote: I thought that was fixed? OK, my apologies for the false alarm. The XML generation seems fixed now. There are other issues with the FPDoc Editor dialog though. Off the top of my head: - It allows you to enter long descriptions for method arguments, when only short descriptions are allowed. I'm not sure what the fpdoc manual says about this. - Same as above, but for enums. I did confirm this with Michael, and the fpdoc manual actually mentions this. - No formatting buttons for things like Unordered List, Ordered Lists, List Items etc. - Underline and Insert URL has the same glyphs on the small buttons. - No place to specify the Package Name when creating a new XML file. It can take a while to figure out why that unit's documentation doesn't appear when you generate fpdoc output. There was more, but this was just a quick list of what I could remember now. 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] Documentation
I have never used FPDoc, but I'd like to understand how it would work in my specific case. I am blind. I use screen reader. I compile my projects without the intervenience of an IDE. No Lazarus, No FPC console ID, I compile my projects with commands like that: fpc myprog.pp If Myprog.pp has the Pasdoc marks, I can create the documentation also by means of commandline. But my question is: FPDoc can be used without an IDE? If true, would I have to create the XML structure manually? Pasdoc is a very good tool, but that's true the source code becomes overcrowded. For my case, Pasdoc seems to be better becouse I won't have an IDE to create the XML. Is this true? 2012/12/17, dev.d...@gmail.com dev.d...@gmail.com: Hi, as the question whether inline or external source docs are the way to go (again?) came up, here are my thoughts (currently searching for the best solution :) ): I personally prefer external docs (and thus started to use fpdoc); reasons are uncluttered source, less scrolling and (if you strictly limit oneself to 80 chars per line) readability on small screens (mobile). At the same time, I use short single (!) line comments to functions, very much the way pasdoc would use them. For sources in an early state (moving code around etc.) external documentation is really annoying, for the detailed documentation of mature source inline docs are simply unsuitable IMHO. Therefore I would really like to see a feature that combines both approaches, small inline comments, e.g. for IDE tooltips and overview documentation together with the possibility to have more detailed infos in external files. Don't get me wrong, that's not an complaint... ... I don't how much work it would be to extend fpdoc, but I really would like to contribute if I knew where to start [and had some more time...] :) Btw. I really like the lazarus fpdoc GUI... Just my 2 cents, d.l.i.w ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal -- Luciano de Souza ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Class procedural type
Am 17.12.2012 22:27 schrieb Ewald ew...@yellowcouch.org: On 17 Dec 2012, at 20:04, Sven Barth wrote: There is no real solution for this. I already thought so, I thank you for clearing this matter up to me. Any ideas? BTW: For time being I fixed it through TProcType(Pointer(@TTestClass.AMethod)), where `TProcType = Procedure;`. I think this boiles down to the same as a class procedure is nothing more than a normal procedure as I see it (except for the name and some other syntax) This is not correct. A class method without static still has a hidden parameter through which the class type is passed. Ah, this is interesting. I didn't know of this hidden parameter, but now that you mention it, it makes sense. So if I declare the method as Class Procedure AMethod; static; 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. 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. Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
