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] 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 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] 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
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
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 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] Registers in loops
On Fri, 14 Dec 2012, Jonas Maebe wrote: On 14 Dec 2012, at 09:26, patspiper wrote: On 13/12/12 21:51, denisgolovan wrote: Hi all Recently I discovered that fpc refuses to use registers in my loops even with optimization turned on (-O1,-O3 used). With the asm code commented out and without any optimization, the registers are used. Indeed, adding inline assembler to a routine disables many optimizations. Doesn't adding the list of modified registers to the 'ASM' block help in this case ? I thought this was why we supported this ? Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] G+ community for Free Pascal and Lazarus
On Tue, 11 Dec 2012, Graeme Geldenhuys wrote: Hi Everybody, Google created a new Community feature in Google+. Below is a link to a community dedicated to Free Pascal and Lazarus. https://plus.google.com/communities/114860965042324270757 If you are on Google+, feel free to visit and join. The community was setup by Marc Hanisch and already has 76 members. Hopefully this will be a nice neutral discussion area with less anal moderation. Not exactly a nice neutral post :-) There is also a Delphi community for those interested: https://plus.google.com/communities/114860965042324270757 The two links are the same ? Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Property alias
On Fri, 7 Dec 2012, Krzysztof wrote: Hi, Interfaces can have aliases for functions: Function MyOtherFunction : Integer; Function IMyInterface.MyFunc = MyOtherFunction; Can normal object have aliases for properties? For example, TControl.Caption. I would like to publish this property in my descendant as MyExtraText. Is this possible? Currently not. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Coping a DataSet
On Mon, 3 Dec 2012, silvioprog wrote: Guys, Is Assign method implemented for dataset in FPC? No, it is not. Datasets differ wildly in how they access and store data. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] BSD
On Wed, 21 Nov 2012, Mark Morgan Lloyd wrote: Somebody's suggesting we ought to be at least looking at BSD. What's the preferred variant from FPC/Lazarus's POV: OpenBSD, FreeBSD etc.? I think Marco mainly uses FreeBSD. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: cannot make debugserver
On Wed, 7 Nov 2012, Graeme Geldenhuys wrote: On 07/11/2012 22:13, bsquared wrote: I like the tiOPF based Logging. Nice work. It is the most reliable logging framework I know. For example, the dbugintf unit in FPC has major issues when used under Windows. If you generate many messages per second (which happens easily when you debug Visitor classes in tiOPF), lost of those messages simply get lost and never display in the debug server. This doesn't seem to happen under Linux though. But with the tiOPF logging you get consistent logging on all platforms, even if you use its own Visual Log Window, or Log File etc. The message are never lost because the tiOPF can buffer the log items. It's difficult to compare the 2 kinds of logging. dbugintf sends the logs to a separate process. tiLog is inside the running application. The former can be used to collect logs from several CGI processes, the latter currently cannot handle this (to my knowledge). That said, I am aware of the windows problem, but have till now not yet found the cause of the problem. Since I use dbugintf exclusively on Linux, I haven't experienced problems yet. I am open for suggestions to fixing the problem, though. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPCUnit checking Single values
On Fri, 2 Nov 2012, ik wrote:
Hello,
I'm trying to check Single value.
I'm doing the following:
a := 1.1;
b := 1.1;
CheckEquals(a, b, Format('val %f does not equal %f', [a, b]));
It reports an error, one of them are 1.1 and the other is 1,10 .
I know about the possible drifts of floating points, but how can I
create a test for such type of values ?
Use the delta:
class procedure AssertEquals(const AMessage: string; Expected, Actual, Delta:
double); overload;
or, if you insist on using the Delphi compatibility layer:
class procedure CheckNotEquals(expected: extended; actual: extended; delta:
extended = 0; msg: string = ''); overload; virtual;
Michael.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Subversion Client/Server Source
On Wed, 24 Oct 2012, Andrew Brunner wrote: Hi there, I'm exploring the possibility adding support for version control in the Aurawin project. I'm needing resources to subversion client/server source to estimate how much time it will take. Does anyone know of official protocol for implementing SVN? Does anyone have any contributions of SVN client/server code in pascal? Why not use the library version of SVN ? This is how Tortoise does it, as far as I know. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Subversion Client/Server Source
On Wed, 24 Oct 2012, Andrew Brunner wrote: On 10/24/2012 08:36 AM, michael.vancann...@wisa.be wrote: Why not use the library version of SVN ? This is how Tortoise does it, as far as I know. I think the focus then would shift to wrapping a library to hook into server over HTTP. I would still need svn protocol or even maybe I could look at Apache svn source (C++) to port to Aurawin's HTTP server. I don't see why you would still need the SVN protocol ? But where is the Official svn documentation for implementing svn over http? Well, the http transport uses WEBDAV. So search for the WEBDAV protocol, and you're set ? Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Subversion Client/Server Source
On Wed, 24 Oct 2012, Andrew Brunner wrote: On 10/24/2012 09:01 AM, michael.vancann...@wisa.be wrote: Well, the http transport uses WEBDAV. So search for the WEBDAV protocol, and you're set ? Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal Ok, looking at WEBDAV and svn. I assume svn is just file based. Implementing WEBDAV will enable svn client to do locking/read/write as needed to the actual repository on disk. Without SVN protocol - I would have to require server distros to have subversion installed. It looks like heavy XML. It will require use the fpc-xml. Are the DOM components proven to be memory leak free at this point? I use them in servers and have not encountered problems in 2 years. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] TurboPower FlashFiler for Free Pascal
On Tue, 23 Oct 2012, Graeme Geldenhuys wrote: Hi, Yeah, a catchy title! ;-) I want to know if anybody here has ever used FlashFiler in Delphi. Was it a good product, and do you think it would be worth the effort porting it to Free Pascal? Or is FlashFiler simply too old and outdated. I mainly use Firebird RDBMS for all my database needs and think it is excellent. I use it in client/server and embedded form under Linux and Windows. But I am also intrigued by the idea of having a true embedded database server - compiled directly into my executable for even easier deployment. Any thoughts on this? Has anybody else started such a port? Allen Harrington blueh...@att.net works on B-Tree filer, which (if I am correct) is the original from Flash Filer. Maybe you can ask about his experiences. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] TurboPower FlashFiler for Free Pascal
On Tue, 23 Oct 2012, Sven Barth wrote: Am 23.10.2012 15:24, schrieb Graeme Geldenhuys: Hi, Yeah, a catchy title! ;-) I want to know if anybody here has ever used FlashFiler in Delphi. Was it a good product, and do you think it would be worth the effort porting it to Free Pascal? Or is FlashFiler simply too old and outdated. I mainly use Firebird RDBMS for all my database needs and think it is excellent. I use it in client/server and embedded form under Linux and Windows. But I am also intrigued by the idea of having a true embedded database server - compiled directly into my executable for even easier deployment. Any thoughts on this? Has anybody else started such a port? I don't know about FlashFiler, but if you don't need your embedded database server to be accessable from outside, I'd suggest you SQLite as an alternative to Firebird ;) If I understand Graeme correctly, he wants it compiled-in (i.e. without dll). SQLite is a separate DLL. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] releasing commercial components as PPU files
On Mon, 22 Oct 2012, Graeme Geldenhuys wrote: Hi, Many Delphi components are sold as full source code, or slightly cheaper (or as trial) as compiled *.DCU files for a specific Delphi version. Could this work with FPC too? Can I release commercial components as PPU files for say FPC 2.6.0 (knowing that those PPU's will not work with any other version of FPC). The only supported compilers will be the officially released versions. That should work. My concern are platforms like Linux, FreeBSD, where the official release is often is source code format. Would it matter if they compile there own FPC 2.6.0 release, and would my PPU's still work in that case? That will most probably not work, although maybe -Ur may provide a solution. It is a discussion I have had several times, and usually the result was negative. As soon as any of the dependencies is recompiled, there are problems. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] releasing commercial components as PPU files
On Mon, 22 Oct 2012, Graeme Geldenhuys wrote: On 2012-10-22 14:15, michael.vancann...@wisa.be wrote: That will most probably not work, although maybe -Ur may provide a solution. Isn't -Ur a default compiler option in official releases? So a 'make all' in the FPC 2.6.0 source directory should use the same compiler options on every Linux setup etc, and be identical to say the binary FPC 2.6.0 Linux release file. Obviously taking into account the same bit size (32-bit or 64-bit Linux). Saying that, looking at the released files on SourceForge again - all releases on Linux, FreeBSD etc have binary releases, so maybe the problem is not so much of an issue, because the officially released FPC versions will be consistent across Linux or FreeBSD. And that's the version I'll support in my components. This is just like Delphi then. It is a discussion I have had several times, and usually the result was negative. As soon as any of the dependencies is recompiled, there are problems. That's why I'm saying only official FPC releases will be supported in the PPU versions of my components. If they want to use FPC 2.6.x (fixes branch) or FPC 2.7.1, then they must buy the source code version of my components. Like I said, it may work. But I think you are in trouble as soon as someone uses e.g. lazarus. I am not sure whether they use the binary release of fpc, or if they compile their own for e.g. windows. If it is the latter, you're in problems. IMHO, in the end it is not worth the trouble. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] releasing commercial components as PPU files
On Mon, 22 Oct 2012, Vincent Snijders wrote: 2012/10/22 Graeme Geldenhuys gra...@geldenhuys.co.uk: On 2012-10-22 14:36, michael.vancann...@wisa.be wrote: I am not sure whether they use the binary release of fpc, or if they compile their own for e.g. windows. If it is the latter, you're in problems. Anybody from the Lazarus development team that can comment here? I am more optimistic than Michael. Because the same source is used, the CRC is the same and no recompile is done. It also depends on the date of the .ppu ? Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] releasing commercial components as PPU files
On Mon, 22 Oct 2012, Vincent Snijders wrote: 2012/10/22 michael.vancann...@wisa.be: On Mon, 22 Oct 2012, Vincent Snijders wrote: I am more optimistic than Michael. Because the same source is used, the CRC is the same and no recompile is done. It also depends on the date of the .ppu ? I don't think so. But I don't mind to be proven otherwise. Well, skipping that check is one of the effects of -Ur, if I remember correctly. But one of the compiler gurus can shed light on that :-) Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] fpmake compiles the same unit multiple times
On Wed, 17 Oct 2012, Graeme Geldenhuys wrote: On 2012-10-17 11:17, Jonas Maebe wrote: fpmake does not know about unit dependencies, Ah OK. Thanks for the explanation. So if I ordered my units better in the fpmake program, then that might reduce the multiple compiling too. If you specify the dependencies right, it should figure out the order by itself. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] fphttpclient close connection?
On Mon, 15 Oct 2012, waldo kitty wrote: i've noted that fphttpclient has a DefaultTimeout of 15 minutes... how can i close the connection after all data is received? That should happen by itself ? Keeping the connection open is currently not supported. The DefaultTimeOut is definitely not a property of the http client. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Using database-specific functionality with TSQLConnector
On Tue, 2 Oct 2012, Reinier Olislagers wrote: Hi list, IBConn:TIBConnection; ... IBConn:=TIBConnection(FConn.ProxyConnection); IBConn.UserName:=FConn.UserName; IBConn.Password:=FConn.Password; IBConn.DatabaseName:=FConn.DatabaseName; ... IBConn.CreateDB; Is that the best/easiest way? Would it make sense to make the proxy code in TSQLConnector public? No. The whole idea is just to hide it. What you want to do is not supported, and is not meant to be supported. To do what you want, we'd need to promote CreateDB to TSQLConnection, and let descendants handle it if they can. Then it can be delegated to the proxy in TSQLConnector. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Assigning pointer address
On Mon, 1 Oct 2012, dhkblas...@zeelandnet.nl wrote: Hi Tomas, Thanks for clarifying. I will use PtrUInt to store the pointer address in. BTW: the documentation it says not to use PtrInt because it's signed and therefore smaller than a pointer (as in max value). Also there seems to be an error in the documentation. On http://www.freepascal.org/docs-html/rtl/system/ptruint.html [4] it is described that PtrUInt is an alias to DWord. However, it depends on the architecture which type it actually is. Could someone please correct the docs? What do you want to see corrected ? On 32-bit systems, it is a DWord. The docs were generated on such a system, so you get this definition. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Assigning pointer address
On Mon, 1 Oct 2012, Reinier Olislagers wrote:
On 1-10-2012 13:55, dhkblaszyk-47ckw973qwsgtviba+r...@public.gmane.org
wrote:
On 1 okt '12, michael.vancanneyt-0is9kj9s...@public.gmane.org wrote:
On Mon, 1 Oct 2012, dhkblas...@zeelandnet.nl
mailto:dhkblaszyk-47ckw973qwsgtviba+r...@public.gmane.orgwrote:
Hi Tomas, Thanks for clarifying. I will use PtrUInt to store the
pointer address in. BTW: the documentation it says not to use PtrInt
because it's signed and therefore smaller than a pointer (as in max
value). Also there seems to be an error in the documentation. On
http://www.freepascal.org/docs-html/rtl/system/ptruint.html [4] it is
described that PtrUInt is an alias to DWord. However, it depends on
the architecture which type it actually is. Could someone please
correct the docs?
What do you want to see corrected ?
On 32-bit systems, it is a DWord. The docs were generated on such a system,
so you get this definition.
If possible I would like to see a remark mentioning that it's a QWord on
64bit and Word on 16bit. That by itself would make thing clearer already.
That sounds good (vaguely remember that PtrUint also depends on OS, but
leaving it to more knowledgeable people to updat the docs anyway)
In the ideal case fpdoc should be adjusted so it can handle these
defines. However this will be very complex I assume.
IIUC, size PtrUint varies by architecture, which is more or less the
point of PtrUint.
Having this variation documented as Darius suggested above makes things
much clearer, because the programmer may be working on one platform and
programming for another (with {$IFDEFS}...).
Yes and no.
You're supposed to treat this as an opaque type, i.e. all you're supposed to
know is that it is:
1) An integer type (signed or not).
2) Same size as a pointer type on all platforms.
If we start specifying when it is of what type, then
a) we need to maintain this.
b) people will start making assumptions.
We exactly need to avoid b)
Michael.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Assigning pointer address
On Mon, 1 Oct 2012, dhkblas...@zeelandnet.nl wrote: fpc-pascal maillist - fpc-pascal@lists.freepascal.org [5] http://lists.freepascal.org/mailman/listinfo/fpc-pascal [6] Nah, I wasn't thinking about letting fpdoc predict anything. Instead though it would be nice to introduce something that helps the documenter flag a certain piece of code and let fpdoc know that it should show alternatives or instead a separate piece of code (similar as examples does). Since fpdoc relies on a pascal parser that only accepts valid pascal code, such a mechanism seems very unlikely to me. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Assigning pointer address
On Mon, 1 Oct 2012, Tomas Hajny wrote:
IIUC, size PtrUint varies by architecture, which is more or less the
point of PtrUint.
Having this variation documented as Darius suggested above makes things
much clearer, because the programmer may be working on one platform and
programming for another (with {$IFDEFS}...).
Yes and no.
You're supposed to treat this as an opaque type, i.e. all you're supposed
to know is that it is:
1) An integer type (signed or not).
2) Same size as a pointer type on all platforms.
If we start specifying when it is of what type, then
a) we need to maintain this.
b) people will start making assumptions.
We exactly need to avoid b)
You're obviously right, but since we include documentation built on a
32-bit architecture as a universal one for all releases/architectures and
since it currently explicitly includes information that 'PtrUInt = DWord',
we should either make sure that this equation doesn't appear in the
documentation (which may be difficult considering how the docs are
created), or (more likely) provide additional information which allows the
reader to interpret the statement correctly. Choosing the right wording
(to stress the opaque nature of this type) is obviously up to you, but a
request for some kind of clarification added to the docs is IMHO
absolutely reasonable.
Absolutely, and I plan to do so :-)
Michael.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] DOM, XMLRead, XMLWrite - cwstring requirement
On Fri, 28 Sep 2012, Graeme Geldenhuys wrote: Hi, Somebody in the fpGUI support newsgroup raised an issue when using BOM, XMLRead units under Linux. Does the use of the DOM, XMLRead and XMLWrite units in FCL (from FPC 2.6.0) require the use of cwstring under Linux? XMLRead uses it, yes. We are working on removing this requirement (Inoussa created a native Object Pascal widestring manager), but we're currently stuck on dealing with a copyright requirement of the Unicode group. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Getting fpcunit test results into a database
On Fri, 28 Sep 2012, Reinier Olislagers wrote: Hi list, Is there existing code available for getting fpcunit test results into a database? Otherwise I'm thinking of writing an XML importer that gets the test results and imports them into a database... handy for regression testing, I'd think. Looking at the XML, that wouldn't be too difficult... but I'm not really an (FPC+) XML afficionado... Why use the XML importer ? The better way is to write a Unit test listener that directly inserts everything in the database. The XML/TXT/Latex output routines are just specialized listeners. All you need to do is create a listener that inserts into a database instead of writing XML/txt/latex... Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] DOM, XMLRead, XMLWrite - cwstring requirement
On Fri, 28 Sep 2012, Graeme Geldenhuys wrote: On 2012-09-28 09:41, michael.vancann...@wisa.be wrote: XMLRead uses it, yes. Umm, so how would that affect applications that normally use UTF-8 packed in AnsiString? Like fpGUI and LCL based applications. It depends on the encoding of the XML, I suppose ? To give you the exact example. He has XML units he would like to unit test. He can use the FPTest Text Runner no problem, but he would prefer to use the FPTest GUI Test Runner (created with fpGUI). Under 64-bit ArchLinux the GUI Test Runner bombs out at runtime. Under 64-bit Ubuntu or OpenSUSE the GUI Test Runner runs without problems. I'm totally baffled as to what would be the cause of the crash at runtime - just on ArchLinux. Me too :-) I'm also not sure how using cwstring unit would affect fpGUI apps that use UTF-8 inside AnsiString containers. (just like LCL does) It all depends on the XML. but we're currently stuck on dealing with a copyright requirement of the Unicode group. I saw a similar post (from a FPC developer) in the Delphi newsgroups. I know. Some of us think that Embarcadero may be violating the copyright :) We have asked clarification of the unicode group, but got no reply yet. (whether we ever will is another matter) Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] DOM, XMLRead, XMLWrite - cwstring requirement
On Fri, 28 Sep 2012, Graeme Geldenhuys wrote: On 2012-09-28 10:01, michael.vancann...@wisa.be wrote: I'm also not sure how using cwstring unit would affect fpGUI apps that use UTF-8 inside AnsiString containers. (just like LCL does) It all depends on the XML. Sorry, I'm not very versed on WideString managers, so excuse if this is a dumb question. Would this (usage of cwstrings) be limited to the XML usage only (reading/writing from file), or to any place in fpGUI or my applications that use String as a data type? TfpgString is defined explicitly as AnsiString so that should be ok, but there are still lots of places (and my own projects) that use String instead. I guess this would cause issues with API calls to external libraries too? No, it is just for the XML reader, since it uses widestrings: it needs to convert the XML to something sensible. Hence it needs the widestring manager. It can be that xmliconv may be sufficient, Sergei Gorelkin needs to comment on this. I know. Some of us think that Embarcadero may be violating the copyright :) After following the posts in the Embarcadero newsgroup, I felt the same way. They are using the data from Unicode.org - repackaging it is irrelevant as far as I'm concerned. Well, the matter is not entirely clear. That is why we decided to ask the unicode group what their opinion is on this matter. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Getting fpcunit test results into a database
On Fri, 28 Sep 2012, Reinier Olislagers wrote: On 28-9-2012 10:43, Graeme Geldenhuys wrote: On 2012-09-28 09:18, Reinier Olislagers wrote: Is there existing code available for getting fpcunit test results into a database? No, but the Test Listener interface makes such an addition very easy. Simply create a TDatabaseListener that implements the ITestListener interface. It's only 5 required methods to implement. Then simply register that test listener with the testing framework (via TestResult.AddListener() call), and it will be fed test results as they happen. Each of those 5 ITestListerner methods will then insert records into the database as needed. Ah, Listeners thanks. Is this listener concept something that's common to more xunit frameworks (junit... etc) or is it an fpcunit invention? It is common to NNNunit testing frameworks. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: SDFDataset users!?
On Tue, 25 Sep 2012, Reinier Olislagers wrote: On 24-9-2012 18:43, Michael Van Canneyt wrote: On Mon, 24 Sep 2012, Reinier Olislagers wrote: On 24-9-2012 17:22, michael.vancanneyt-0is9kj9sb0a-xmd5yjdbdmrexy1tmh2...@public.gmane.org wrote: On Mon, 24 Sep 2012, Reinier Olislagers wrote: Finally, I'll post on the forum that sdf compatibility is not one of the goals of sdfdataset. Is there some defined on-disk format that sdfdataset should be following? As I understood it, it is either fixed length or CSV. CSV as in http://tools.ietf.org/html/rfc4180 People can only go by what they see (they can't read your mind when you committed sdfdataset). There is: - the unit name (sdfdataset) - the comments - the code - the output All of this makes it in my opinion more likely to be SDF than CSV. Like I said, I had never heard of SDF. Look, for me, this is not a requirement set in stone, I am quite flexible. You guys asked what the original idea was, and I explained some of the history behind the dataset. If the desire is to have a TSDFDataset (whatever the specs) and a separate CSV dataset, fine, we'll make it so, this is really not a problem. I don't want anyone to feel that he has wasted his time :-) Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: SDFDataset users!?
On Tue, 25 Sep 2012, Reinier Olislagers wrote: That is indeed another approach that doesn't require specs nor docs. Unfortunately only available to those that have the keys to kingdom :) Well, I think that trying to let TSDFDataset conform to certain SDF specs is trying to do some unjustified backfitting. If conforming to the format that is specified in all existing evidence is wrong but conforming to some format that is never mentioned at all is right, I give up. IMO this is no way to run any serious development effort: don't expect people to read minds about what was intended if that is not documented, *especially* in cases like this where any knowledgeable person's obvious conclusion is the one you don't want them to make. Also, first accepting patches that explicitly aim for sdf/delimitedtext compatibility (bug 17285,22213) and then stating the opposite is an excellent incentive for me to drop everything that's sdfdataset related. IMHO, it should do fixed format and CSV as indicated by the RFC I posted. All the rest is nice, but not required from my perspective. It's not required anymore from my perspective either. I just wanted to fix sdfdataset so that it does what it says on the tin. I'd suggest: 1. adding a readme as indicated in my other mail so that users and developers do not fall into the same trap Hoho, there is no trap :-) 2. documenting similar unwritten assumptions in other relevant units as well. Not doing so is a great way to discourage contributors That is definitely not the intention. See my other mail. I was frankly surprised by the strong responses I got. Any assumptions I made were mine, and definitely not the law, I just gave them as 'historical background', because that is how I perceived the original question :-) Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: SDFDataset users!?
On Tue, 25 Sep 2012, Reinier Olislagers wrote: On 25-9-2012 10:11, michael.vancann...@wisa.be wrote: On Tue, 25 Sep 2012, Reinier Olislagers wrote: On 24-9-2012 18:43, Michael Van Canneyt wrote: On Mon, 24 Sep 2012, Reinier Olislagers wrote: On 24-9-2012 17:22, michael.vancanneyt-0is9kj9sb0a-xmd5yjdbdmrexy1tmh2...@public.gmane.org wrote: On Mon, 24 Sep 2012, Reinier Olislagers wrote: Finally, I'll post on the forum that sdf compatibility is not one of the goals of sdfdataset. Is there some defined on-disk format that sdfdataset should be following? As I understood it, it is either fixed length or CSV. CSV as in http://tools.ietf.org/html/rfc4180 People can only go by what they see (they can't read your mind when you committed sdfdataset). snip All of this makes it in my opinion more likely to be SDF than CSV. Like I said, I had never heard of SDF. I understand (and appreciate) your reasoning when you committed it. Having a CSV dataset is very handy. Before I understood the full horror of what SDF really means, especially as implemented by Delphi (see the nasty behaviour when you add spaces after a quoted text and before a delimiter) I thought SDF was really some form of CSV, too. (Well I suppose it is, it's just not RFC4180 CSV unless you e.g. decide to quote everything. IIRC then it actually complies with RFC4180). Look, for me, this is not a requirement set in stone, I am quite flexible. So am I... see below. You guys asked what the original idea was, and I explained some of the history behind the dataset. Not really, I asked what the specs were ;) If the desire is to have a TSDFDataset (whatever the specs) and a separate CSV dataset, fine, we'll make it so, this is really not a problem. Actually, if you are happy with an SDFDataset that complies with RFC4180 CSV (but not SDF), I would vastly prefer that over the atrocity that is SDF - as long as this requirement/behaviour is quite clearly specified (e.g. in a readme). No problem :-) If you think that any changes to sdfdataset to make it RFC4180 compliant are acceptable to current users, fine by me ;) I have not seen any evidence that it has ever been used other than for CSV, but I may be wrong. So I suspect that this should be acceptable. The csvdocument [1] code has a very nice record-by-record CSV parser and writer with test set that aims to be RFC4180; this could be used for interoperability testing or even, if evidence by test set failures, used instead of parts of the current code. I'm fine with that. I don't want anyone to feel that he has wasted his time :-) Well, getting clarity about what the on disk format must be is worth it even though I can't really say I enjoyed this particular episode :) Even better, as I said, if everybody is happy with RFC4180 CSV, I vastly prefer that format to SDF and would consider my time well spent. I'm sure tatamata from the forum will appreciate it too (AFAIR, his ZMSQL is based on sdfdataset). I'm just not interested right now in implementing either a test set or the changes myself, but perhaps somebody else is. Well, in the not-too-far future, I'll spend time on improving the DB testsuite. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] SDFDataset users!?
On Mon, 24 Sep 2012, Reinier Olislagers wrote: Hi list, There are some bugs open for sdfdataset, e.g. 22894 Sdfdataset: empty file with FirstLineAsSchema reports Recordcount 1 instead of 0 22882 SDFDataset .AllowMultiLine does not support multiline import I've written a test suite to check sdfdataset behaviour. An older version of this is already in FPC trunk in the database tests (tcsdfdata.pp). The test set can be donwnloaded here: https://bitbucket.org/reiniero/fpc_laz_patch_playground/downloads Currently, taazz on the forum is improving sdfdataset against this test set: http://lazarus.freepascal.org/index.php/topic,18224.0.html If there are any sdfdataset users out there: 1. I'd very much appreciate additional test cases for tcsdfdata.pp. Especially if you think there are issues with current sdfdataset, please don't hesitate to send an tcsdfdata.pp with more tests. 2. Presumably sdfdataset is used to exchange data with Delphi systems using tstrings.delimitedtext. Therefore I'm stressing Delphi compatibility in my tests. Do you think this is justified? No, definitely not. The two are totally unrelated. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Firebird: bulk insert performance: suggestions?
On Fri, 7 Sep 2012, Reinier Olislagers wrote:
For my Dutch postcode program https://bitbucket.org/reiniero/postcode
with an embedded Firebird 2.5 database, I allow users to read in a CSV
file with new or updated postcode data.
I use sqldb, FPC x86.
I'd like to get your suggestions on speed improvements.
I try to get the data into a temporary table as quickly as possible.
Later on, a stored procedure will normalize the data and insert
to/update various tables (with postcode, city, street information, etc).
Because I also allow querying information, I set up 2
connections+transactions: for reading and writing in my database class
constructor, and destroy them in the destructor.
However, (currently) my application controls the database and I know
that querying and bulk inserts at the same time is impossible.
The write transaction has this code:
FWriteTransaction.Params.Add('isc_tpb_concurrency');
FWriteTransaction.Params.Add('isc_tpb_write');
FWriteTransaction.Params.Add('isc_tpb_no_auto_undo'); //disable
transaction-level undo log, handy for getting max throughput when
performing a batch update
My code loads an ANSI CSV file into a csvdocument in memory (about
50meg), then goes through it, and calls an insert procedure for each
record (converting the field contents to UTF8):
FDBLayer.BulkInsertUpdateRecord(
SysToUTF8(Postcodes.Cells[ProvinceField,LineNum]),
SysToUTF8(Postcodes.Cells[CityField,LineNum]),
SysToUTF8(Postcodes.Cells[PostcodeField,LineNum]),
SysToUTF8(Postcodes.Cells[StreetField,LineNum]),
StrToInt(Postcodes.Cells[NumberLowestField,LineNum]),
StrToInt(Postcodes.Cells[NumberHighestField,LineNum]),
Even,
Latitude,
Longitude);
Relevant snippets from the insert procedure:
QuerySQL='INSERT INTO BULKINSERTDATA '+
'(PROVINCENAME,CITYNAME,POSTCODE,STREETNAME,LOW,HIGH,EVEN,LATITUDE,LONGITUDE)
'+
'VALUES ( '+
':PROVINCENAME,:CITYNAME,:POSTCODE,:STREETNAME,:LOW,:HIGH,:EVEN,:LATITUDE,:LONGITUDE)';
then the transaction is started (if it is inactive) and the query
parameters are filled (using Query.Params.ParamByName, but I don't
suppose that would be a big slowdown??); finally the SQL is executed.
The transaction is left open.
Do you prepare the query before you start the batch ?
If not, it is prepared on every insert, which is inherently slower.
Currently, after every 100 records, the transaction is committed:
if (linenum mod 100=0) then
FDBLayer.BulkInsertCommit(false);
IIRC, advice on the Firebird list is to play with this interval; any
suggestions? Given the aggressive nature of the transaction parameters,
I might even dispense with it.
I once did tests with that (600.000 records) and did not notice any influence
of the transaction control.
Michael.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Firebird: bulk insert performance: suggestions?
On Fri, 7 Sep 2012, Reinier Olislagers wrote: On 7-9-2012 13:12, michael.vancanneyt-0is9kj9s...@public.gmane.org wrote: On Fri, 7 Sep 2012, Reinier Olislagers wrote: then the transaction is started (if it is inactive) and the query parameters are filled (using Query.Params.ParamByName, but I don't suppose that would be a big slowdown??); finally the SQL is executed. The transaction is left open. Do you prepare the query before you start the batch ? If not, it is prepared on every insert, which is inherently slower. I didn't do an explicit .Prepare, but I've added it, thanks. I thought sqldb would prepare automatically if you are using parameters though? If it prepares the statement automatically, it also unprepares it. (at least, it should :) ) Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Delphi's anonymous functions in Free Pascal
On Wed, 29 Aug 2012, Arioch wrote: Florian Klämpfl wrote This is the prototypical way to run a function over each element in a collection, returning the results. (map (lambda (x) (+ x 1)) '(1 2 3)) - (2 3 4) I still don't see why this cannot be done by procedure variables: one can easily pass a procedure reference to a compare function to any sort library call. Sorry for resurrecting al thread, but p[erhaps better to keep things together. 1) anonymous methods in Delphi are made in very Pascalish way, a lot of wording, a lot of boilerplate. That adds to readability, but makes their use much harder. If you have relatively complex 4-5 lines function, then the overhead is slightly noticeable. But such functions are a borderline to me, having them anonymous hampers both ease of read and ease of debug. I know C++ fans how say that begin/end are awfully long. Well, Delphi style of anonymous functions would frighten them even more. I don't think anonymous functions should be added to the compiler at all. They are IMHO a negation of what pascal stands for. If your programming style is so strange that you need lamba functions or anonymous functions, then Pascal is simply not for you. Michael.___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Delphi's anonymous functions in Free Pascal
On Thu, 30 Aug 2012, Arioch wrote: Ralf A. Quint wrote At 12:09 AM 8/30/2012, michael.vancanneyt@ wrote: They are IMHO a negation of what pascal stands for. If your programming +1 Well, the same should be told about everything modern pascal is. Open and dynamic arrays, pointer math, objects, generics, even units. It was all breaking the initial Pascal strictness and rigidness. Only pointer math breaks rigidness. The others do not, they enhance it. Pascal is about readable, clearly structured, strongly typed code. Because what was counted large blocks deserving their own explicit naming back then - now seems trivial small detail. Generics are alien to Pascal no more no less than closures. Exactly. If it had been up to me, they would not have been included either. Till now, I've seen only 1 actual use of generics in general component code, which kind of supports my theory that the only thing they are useful for is to create a list and collection kind of classes that do not need typecasts. which I think is too little justification, because that could have been achieved differently IMHO. I started to use lambda functions in Javascript, where they are ubiquitous. Except for some trivial cases, I ended up naming them anyway, so they could be reused. I just don't see enough justification for them, given that Pascal offers enough other structures to achieve the same effect. Not every conceivable use case justifies a new language feature. Especially such an abomination as lambda functions, which totally destroys readability. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Delphi's anonymous functions in Free Pascal
On Thu, 30 Aug 2012, Arioch wrote: If the new features conform to the readability [snip] But afterall i am quitting on that. Since FPC are lacking closures i am sure here are mostly people who personally dislike them. I wanted to document why closures are good and do matter. Hopefully i did it to the extent i was able to. Surely i would not be able to convince you infinite time. So the rest of arguments would be questions of personal tastes and it would bring nothing but flamewar. Regarding this: I wish to stress that my views on lambdas or closures are my own; Other people on the compiler team may have different ideas, so maybe they will make it into the compiler. Just like Generics did, or advanced records and some other weird Delphi things of which I totally do not see the use :) But - and I think the whole compiler team shares this idea - if implemented, it will be in a pascal-ish way, i.e. rather verbose. Simply because it is Pascal, after all, and not some C derivative language (java, C#, Javascript, PHP, Perl whatnot...) Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Delphi's anonymous functions in Free Pascal
On Thu, 30 Aug 2012, Arioch wrote: From personal experience, when i first time saw how pascalish is closures implementation in Delphi i just admired the ease in which that concept was fused into the language of very different style built upon very different ideas. It was so elegant when reading docs, i admired it. Like probably you do. Not really: it breaks my eyes, just as it does in JavaScript :( Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Easier fpmake
On Wed, 22 Aug 2012, Tomas Hajny wrote: On 22 Aug 12, at 19:03, Michael Van Canneyt wrote: Hi Michael, As you know, FPC uses fpmake to compile everything in packages. As I've been steadily improving fcl-passrc for fpdoc, (it's now almost on par with the compiler, barring errors and assembler statetements), I created a small tool pas2fpm which takes as input a bunch of unit names, and outputs a ready-to-go fpmake.pp file. This means that pas2fpcm -o fpmake.pp *.pp is all you need to create a fpmake.pp file. (provided the shell expands wildcards) It analyses the sources, and creates an fpmake file that contains all units, the units have the correct dependencies (it analyses that too) and sets the UseResourceStrings property. If a particular source file is not compilable (parseable), it will add it anyway, but with a comment. The resulting fpmake.pp should compile and do what it needs to do. The tool can be found in utils/pas2fpm. I'd be pleased to hear of any comments or suggestions for improvement. Like support for platforms where wildcards are not expanded by shell? ;-) Good point. I will do so. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Unit testing aid...
On Wed, 22 Aug 2012, Martin wrote: On 22/08/2012 18:08, Michael Van Canneyt wrote: Hi, for those that do unit testing, I committed a small tool pas2ut which analyses a unit, and creates a unit with a number of (empty) test cases. Obviously, the unit should be compileable (well, at least it must be parseable). I just updated from SVN (after make clean), using fpc 2.6.0 (only ppc, no full install, I admit it could be may fault, I still dare to ask for help) My mistake. I forgot to add a dependency. So, number 2 on the to-do list for pas2fpm: Add tracking of package dependencies :) Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] TSQLDBLibraryLoader committed for SQLDB
On Wed, 22 Aug 2012, Ludo Brands wrote: After recent discussions about which library to load when loading DB client libraries, I changed the default names for Firebird, MySQL, Postgres. That was well in time ;) Thanks. Another little bug and patch in http://bugs.freepascal.org/view.php?id=22691 Applied, thank you. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] TSQLDBLibraryLoader committed for SQLDB
On Wed, 22 Aug 2012, Ludo Brands wrote: (In the IDE: drop, set connector type from picklist, maybe change library name, set to enabled). I'm having some problems using this in the IDE. The picklist is empty. Probably something missing in procedure TSQLDBConnectorTypePropertyEditor.GetValues( Proc: TGetStrProc); Var L : TStringList; I : Integer; begin L:=TStringList.Create; try for I:=0 to L.Count-1 do Proc(L[i]); finally L.Free; end; end; because that is a no-op. Also, if I understand the mode of operation correctly, the TSQLDBLibraryLoader, when enabled, loads the library before the TxxxConnection tries to load it. But how can you be sure TSQLDBLibraryLoader is streamed before a TxxxConnection that has connected set to true First: When committing, I has a problem with conflicts. It seems that while resolving these conflicts, a line got lost. I re-added that line. Second, this problem is known, but there is no good solution to this problem, except not leaving connected to true. (which is bad practice anyway IMHO). There are more problems: the library name is not cross-platform, so the project will no longer be cross-platform. Which is a far more serious problem, IMHO. (and one which would exist even if I had followed your suggestion of implementing the property in TSQLConnection). Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] TSQLDBLibraryLoader committed for SQLDB
On Wed, 22 Aug 2012, Ludo Brands wrote: There are more problems: the library name is not cross-platform, so the project will no longer be cross-platform. Which is a far more serious problem, IMHO. (and one which would exist even if I had followed your suggestion of implementing the property in TSQLConnection). That is not a problem, that is a given. When you use the OI to fill in platform specific values the app becomes non cross-platform, whether it is a library name or an InitialDir in TFileDialog or a Filter in TFileNameEdit or ... (too long a list). Indeed. To fix the problem of Loaded, I will see for some kind of hook mechanism. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Possible RTFM question: is there something like an IsRootPath() function?
On Mon, 20 Aug 2012, Bart wrote: Hi, Does fpc have a function that determines if a given paths is the root (e.g. '/' in Linux, 'F:\' in Windows)? I could not find such a thing. There is no such function. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: fpdoc executable both in bin and utils\fpdoc - but not fpdoc.css
On Tue, 14 Aug 2012, Reinier Olislagers wrote: On 12-8-2012 10:35, Reinier Olislagers wrote: In my (Windows) SVN fpc installs, I can find the fpdoc executable both under the bin directory as well as utils\fpdoc However, I've only found fpdoc.css in utils\fpdoc (and a different one in packages\fcl-res\xml) but not in the bin directory. IIRC, fpdoc picks up fpdoc.css when generating HTML/CHM output. Shouldn't fpdoc.css be also present under the bin directory then? No. You're responsible for putting this file wherever it needs to be put. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: fpdoc executable both in bin and utils\fpdoc - but not fpdoc.css
On Tue, 14 Aug 2012, Reinier Olislagers wrote: On 14-8-2012 9:46, michael.vancann...@wisa.be wrote: On Tue, 14 Aug 2012, Reinier Olislagers wrote: On 12-8-2012 10:35, Reinier Olislagers wrote: In my (Windows) SVN fpc installs, I can find the fpdoc executable both under the bin directory as well as utils\fpdoc However, I've only found fpdoc.css in utils\fpdoc (and a different one in packages\fcl-res\xml) but not in the bin directory. IIRC, fpdoc picks up fpdoc.css when generating HTML/CHM output. Shouldn't fpdoc.css be also present under the bin directory then? No. You're responsible for putting this file wherever it needs to be put. Fine, I understand that, but what is fpdoc then doing in the bin directory? The binary ? Where would you put it if not in bin ? Is it used in some other program? This program presumably either: - uses its own copy or version of the css file - references the fpdoc.css in the utils\fpdoc directory (in which case: why not use the fpdoc executable there) - is not interested in the css file The fpdoc system uses a fpdoc.css file for style. We provide one which can be used, but you are under no obligation to use that file. You can perfectly create one from scratch, or adapt the existing one. Since we do not know what you want to do, we do not 'automagically' copy it to the output. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: fpdoc executable both in bin and utils\fpdoc - but not fpdoc.css
On Tue, 14 Aug 2012, Reinier Olislagers wrote: On 14-8-2012 10:31, michael.vancann...@wisa.be wrote: On Tue, 14 Aug 2012, Reinier Olislagers wrote: On 14-8-2012 9:46, michael.vancann...@wisa.be wrote: On Tue, 14 Aug 2012, Reinier Olislagers wrote: On 12-8-2012 10:35, Reinier Olislagers wrote: In my (Windows) SVN fpc installs, I can find the fpdoc executable both under the bin directory as well as utils\fpdoc However, I've only found fpdoc.css in utils\fpdoc (and a different one in packages\fcl-res\xml) but not in the bin directory. IIRC, fpdoc picks up fpdoc.css when generating HTML/CHM output. Shouldn't fpdoc.css be also present under the bin directory then? No. You're responsible for putting this file wherever it needs to be put. Fine, I understand that, but what is fpdoc then doing in the bin directory? The binary ? Where would you put it if not in bin ? Sure, sure, but my point was the connection between fpdoc.css and fpdoc.exe... Not that important, please see below. The fpdoc system uses a fpdoc.css file for style. We provide one which can be used, but you are under no obligation to use that file. You can perfectly create one from scratch, or adapt the existing one. Since we do not know what you want to do, we do not 'automagically' copy it to the output. The following is meant as constructive advice, not criticism: Very well, how many people do you think use fpdoc *and* customize fpdoc.css? Even then, copying fpdoc.css to the bin directory would give a sensible default, no? If people want to customize it, replace it etc they can then always do so. If you want your fpdoc.exe usable from the bin directory, I'd just copy over fpdoc.css during install. Now we've got 2 different behaviours: - fpdoc in the source directory has fpdoc.css and will generate chm/html files with it - fpdoc in the bin directory doesn't have it. In my view this difference in behaviour is unnecessary and only server to needlessly further increase the complexity of the fpdoc system... There is no difference in behaviour. If you do not specify the location with --css-file, then fpdoc does not look in the bin directory, only in the current working directory. That we should distribute the file somewhere is something I agree on, but I do not think it should be in the bin directory; it's not a binary, after all. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: fpdoc executable both in bin and utils\fpdoc - but not fpdoc.css
On Tue, 14 Aug 2012, Reinier Olislagers wrote: On 14-8-2012 10:43, michael.vancann...@wisa.be wrote: On Tue, 14 Aug 2012, Reinier Olislagers wrote: On 14-8-2012 10:31, michael.vancann...@wisa.be wrote: On Tue, 14 Aug 2012, Reinier Olislagers wrote: On 14-8-2012 9:46, michael.vancann...@wisa.be wrote: On Tue, 14 Aug 2012, Reinier Olislagers wrote: Fine, I understand that, but what is fpdoc then doing in the bin directory? The binary ? Where would you put it if not in bin ? Sure, sure, but my point was the connection between fpdoc.css and fpdoc.exe... Not that important, please see below. The fpdoc system uses a fpdoc.css file for style. We provide one which can be used, but you are under no obligation to use that file. You can perfectly create one from scratch, or adapt the existing one. Since we do not know what you want to do, we do not 'automagically' copy it to the output. The following is meant as constructive advice, not criticism: Very well, how many people do you think use fpdoc *and* customize fpdoc.css? Even then, copying fpdoc.css to the bin directory would give a sensible default, no? If people want to customize it, replace it etc they can then always do so. If you want your fpdoc.exe usable from the bin directory, I'd just copy over fpdoc.css during install. Now we've got 2 different behaviours: - fpdoc in the source directory has fpdoc.css and will generate chm/html files with it - fpdoc in the bin directory doesn't have it. In my view this difference in behaviour is unnecessary and only server to needlessly further increase the complexity of the fpdoc system... There is no difference in behaviour. If you do not specify the location with --css-file, then fpdoc does not look in the bin directory, only in the current working directory. Right. But there still is a difference between: cd c:\development\fpc\bin\i386-win32 fpdoc ...etc... and cd c:\development\fpc\utils\fpdoc fpdoc ...etc... I do not understand what you try to say. Please explain ? As far as I know, only 1 copy of fpdoc is distributed. So where you get the second path from, I do not know. That we should distribute the file somewhere is something I agree on, but I do not think it should be in the bin directory; it's not a binary, after all. Neither are fp.ans fpc.cfg yylex.cod program.pt cvsup.tdf ... but they still live in my fpc bin directory... innocent expressionProbably supporting files of some sort?/innocent expression I suspect the programs that use those files are coded to look in the program directory. They stem from the Dos age, and it was common practice in those days. Meanwhile I think the world has evolved to other practices :-) Still, I'm glad you think the file should be distributed somewhere... Well, we're trying hard not to be totally unreasonably pig-headed. It takes a lot of effort, but we try nonetheless :-) Jokes aside: I leave it up to the Windows setup builders to decide where it should go. If they decide on the bin dir anyway, then so be it... Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: fpdoc executable both in bin and utils\fpdoc - but not fpdoc.css
On Tue, 14 Aug 2012, Reinier Olislagers wrote: On 14-8-2012 11:34, Marco van de Voort wrote: In our previous episode, Reinier Olislagers said: in packages\fcl-res\xml) but not in the bin directory. IIRC, fpdoc picks up fpdoc.css when generating HTML/CHM output. Shouldn't fpdoc.css be also present under the bin directory then? Thanks, Reinier Bump. Any reactions? The scripts that generate have their own locations set to the fpdoc.css Since generating docs requires additional repositories (like fpcdoc), it is not a standard feature of installs anyway. True for fpc source docs... So you're saying FPC users who don't have the source installed (e.g. on Debian) should get the source, download fpdoc.css separately or create their own if they want to generate HTML documentation of their own code. Doesn't seem user friendly. There is no discussion that fpdoc.css should be distributed. The only question is: where should we put it ? Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: fpdoc executable both in bin and utils\fpdoc - but not fpdoc.css
On Tue, 14 Aug 2012, Reinier Olislagers wrote: On 14-8-2012 13:50, michael.vancanneyt-0is9kj9s...@public.gmane.org wrote: On Tue, 14 Aug 2012, Reinier Olislagers wrote: On 14-8-2012 11:34, Marco van de Voort wrote: In our previous episode, Reinier Olislagers said: in packages\fcl-res\xml) but not in the bin directory. IIRC, fpdoc picks up fpdoc.css when generating HTML/CHM output. Shouldn't fpdoc.css be also present under the bin directory then? Thanks, Reinier Bump. Any reactions? The scripts that generate have their own locations set to the fpdoc.css Since generating docs requires additional repositories (like fpcdoc), it is not a standard feature of installs anyway. True for fpc source docs... So you're saying FPC users who don't have the source installed (e.g. on Debian) should get the source, download fpdoc.css separately or create their own if they want to generate HTML documentation of their own code. Doesn't seem user friendly. There is no discussion that fpdoc.css should be distributed. Yes, you told me. I'm asking because I'm not sure what Marco wanted (and anybody else). The only question is: where should we put it ? Apparently the bin directory is not satisfactory (though I don't see why)? 2 reasons: 1. I do not think you should put such files there. I know that there are some historic reasons for putting some 'extra' things there, but I think we should change that DOS habit. 2. fpdoc.exe will not search it there. By putting it there you will create the expectation that it will search for it there (as some of the other utils do), but it will not. On my Laz install (installed by Win installer) I only have bin,msg,units under the fpc directory. Perhaps there are others in other versions... What about the fpc root directory then? I think it is better to have it in fpc/docs. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: fpdoc executable both in bin and utils\fpdoc - but not fpdoc.css
On Tue, 14 Aug 2012, Reinier Olislagers wrote: On 14-8-2012 14:40, michael.vancanneyt-0is9kj9s...@public.gmane.org wrote: On Tue, 14 Aug 2012, Reinier Olislagers wrote: On 14-8-2012 13:50, michael.vancanneyt-0is9kj9sb0a-xmd5yjdbdmrexy1tmh2...@public.gmane.org wrote: On Tue, 14 Aug 2012, Reinier Olislagers wrote: On 14-8-2012 11:34, Marco van de Voort wrote: In our previous episode, Reinier Olislagers said: in packages\fcl-res\xml) but not in the bin directory. IIRC, fpdoc picks up fpdoc.css when generating HTML/CHM output. Shouldn't fpdoc.css be also present under the bin directory then? The only question is: where should we put it ? snip On my Laz install (installed by Win installer) I only have bin,msg,units under the fpc directory. Perhaps there are others in other versions... What about the fpc root directory then? I think it is better to have it in fpc/docs. Ok. So: fpc\docs for Windows and on Linux/Unix/(OSX??) Jonas' suggestion $PREFIX/share/doc/fpc-$fpcversion/ Seems like the reasonable thing, yes. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: fpdoc executable both in bin and utils\fpdoc - but not fpdoc.css
On Tue, 14 Aug 2012, Tomas Hajny wrote: On Tue, August 14, 2012 15:15, michael.vancann...@wisa.be wrote: On Tue, 14 Aug 2012, Reinier Olislagers wrote: On 14-8-2012 14:40, michael.vancanneyt-0is9kj9s...@public.gmane.org wrote: On Tue, 14 Aug 2012, Reinier Olislagers wrote: On 14-8-2012 13:50, michael.vancanneyt-0is9kj9sb0a-xmd5yjdbdmrexy1tmh2...@public.gmane.org wrote: On Tue, 14 Aug 2012, Reinier Olislagers wrote: On 14-8-2012 11:34, Marco van de Voort wrote: In our previous episode, Reinier Olislagers said: in packages\fcl-res\xml) but not in the bin directory. IIRC, fpdoc picks up fpdoc.css when generating HTML/CHM output. Shouldn't fpdoc.css be also present under the bin directory then? The only question is: where should we put it ? snip On my Laz install (installed by Win installer) I only have bin,msg,units under the fpc directory. Perhaps there are others in other versions... What about the fpc root directory then? I think it is better to have it in fpc/docs. Ok. So: fpc\docs for Windows and on Linux/Unix/(OSX??) Jonas' suggestion $PREFIX/share/doc/fpc-$fpcversion/ Seems like the reasonable thing, yes. Actually, the file is more a configuration file for fpdoc than its documentation, isn't it? From this point of view, shouldn't SysUtils.GetAppConfigDir serve as the most reasonable location? It is definitely not a config file. It is a file that must be copied to every project you want to document with fpdoc. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: fpdoc executable both in bin and utils\fpdoc - but not fpdoc.css
On Tue, 14 Aug 2012, Tomas Hajny wrote: $PREFIX/share/doc/fpc-$fpcversion/ Seems like the reasonable thing, yes. Actually, the file is more a configuration file for fpdoc than its documentation, isn't it? From this point of view, shouldn't SysUtils.GetAppConfigDir serve as the most reasonable location? It is definitely not a config file. It is a file that must be copied to every project you want to document with fpdoc. If I understand it correctly, this is only the case for plain HTML whereas CHM includes it internally (and from this point of view it is much more a configuration file influencing the output than part of fpdoc documentation - see also the comment from Marco). As far as I know, CHM does not include it internally. It expects it to be there, just as the other HTML files should be there. From certain point of view it is unfortunate that the same file (equally named and potentially even equally placed) is used as the default template for generation of new documents with fpdoc and also for viewing of the (distributed) FPC documentation because fpdoc users may want to change the style of their generated documents but they may not be interested in changing the design of our FPC documentation. The file in the docs dir is there so they can copy it. It will never be used directly. Anyway, it's all moot now, I will let fpdoc generate the file. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] WeekDay outdated?
On Mon, 13 Aug 2012, Marco van de Voort wrote: In our previous episode, Jonas Maebe said: I am not able to use this function: http://www.freepascal.org/docs-html/rtl/dos/weekday.html nor can I find it in the sources. Does it still exist? If yes, how to use it? Which unit? DOS does not work. The weekday function only exists in the unix version of the Dos unit. It should probably either be removed from its interface, or added to the common part of the Dos unit (there's nothing unix-specific about it). As a first step I added platform; modifiers to all unix specific functions in unix' unit dos. The generic function to calculate the day of the week is http://www.freepascal.org/docs-html/rtl/sysutils/dayofweek.html IIRC in Delphi dateutils.dayoftheweek is prefered since its introduction in D6 which introduced dateutils and ISO 8601 compatible functions. (the definition of the first day of the week differs from region to region iirc) But the FPC docs don't mention what the first day of the week is for that function, OR its compliance. It is monday=1..sunday=7, and the whole unit is supposed to be ISO 8601 compliant. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Initialization of class field
On Tue, 31 Jul 2012, Krzysztof wrote: Hi, I'm reading about variable initialization (http://www.freepascal.org/docs-html/ref/refse22.html) . Can I initialize class field too? Like in Java: type TMyClass = class private FSomeField: Integer = 123; end; I always initialize this in overrided constructor, but above example is much faster. Object Pascal currently does not support this, except maybe for static class variables. The compiler people should confirm this. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Generating templates with FPTemplate
On Fri, 27 Jul 2012, Luciano de Souza wrote: Michael, Your example is very clear. I am not very good to understand source codes. But this style seems to be very good and logical. It's really wonderful: FPC owns units for everything! Well, I use FPC for everything. So, I need tools for everything, and what better way than to make these tools open source and share them ? This way everyone benefits, me included... Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Inter-process communication, a cautionary tale
On Wed, 18 Jul 2012, Mark Morgan Lloyd wrote: michael.vancann...@wisa.be wrote: On Wed, 18 Jul 2012, Mark Morgan Lloyd wrote: I was reminded of this when somebody was asking about portable signalling APIs the other day, but I think it's also relevant to discussion of e.g. how to pass a keyword to a help viewer. I am obviously aware of the fact that FPC has an IPC unit which uses a temporary file, although I have always assumed that that was more to support targets like DOS that had absolutely no concept of pipes or sockets. But perhaps it really is the safest choice in all cases. In which unit did you find this ? The IPC unit in FPC uses a unix socket on unix, and on windows a Windows window handle to copy data. I believe I'm thinking of TSimpleIPC etc. My apologies if I've got this wrong, or if what I read was outdated Ignorance of the law is no defense). No need to apologize, I'm just curious where you got your info from. The implementation has been the same since day 1, which means your statement puzzles me. So instead of re-inventing the wheel, maybe have a closer look again at the standard IPC mechanisms. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Inter-process communication, a cautionary tale
On Wed, 18 Jul 2012, Mark Morgan Lloyd wrote: michael.vancann...@wisa.be wrote: No need to apologize, I'm just curious where you got your info from. The implementation has been the same since day 1, which means your statement puzzles me. So instead of re-inventing the wheel, maybe have a closer look again at the standard IPC mechanisms. I will do, but I do note that http://lazarus-ccr.sourceforge.net/docs/rtl/ipc/index.html explicitly says that It works only on the linux operating system. Where's the source- I can only see ./fpcsrc/rtl/unix/ipc.pp I meant the SimpleIPC unit from the FCL: http://lazarus-ccr.sourceforge.net/docs/fcl/simpleipc/index.html Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: RE : [fpc-pascal] Database problem on Solaris SPARC
On Mon, 16 Jul 2012, Mark Morgan Lloyd wrote:
Mark Morgan Lloyd wrote:
[Nod], understood. Hit a slight snag here with trunk FPC + trunk Lazarus:
Target OS: Solaris for SPARC
Compiling sqldblaz.pas
Compiling registersqldb.pas
registersqldb.pas(58,3) Fatal: Can't find unit ibconnection used by
registersqldb
Fatal: Compilation aborted
make[2]: *** [sqldblaz.ppu] Error 1
make[2]: Leaving directory
`/export/home/local-share/lazarus-trunk/components/sqldb'
make[1]: *** [bigide] Error 2
make[1]: Leaving directory
`/export/home/local-share/lazarus-trunk/components'
make: *** [bigidecomponents] Error 2
-bash-3.00$ svn up
At revision 37922.
Anybody got any quick suggestions? all builds OK but I presume I need
bigide because I've used the TQuery etc. on the form.
Still getting this at FPC 21919 and Laz 37954: can anybody recommend a quick
hack as a workaround, or do I Mantis it?
I don't think Firebird works on Solaris or SPARC cpus, so it makes no sense
to compile in firebird support on that platform.
Remove the ibconnection unit or put it in an {$IFNDEF SOLARIS}. (or should
that be SUNOS ?)
You'll have to remove TIBConnection from the registercomponents call as
well.
If that works, we'll put it in the sources in SVN.
Michael.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Should FCL documentation be splitted?
On Thu, 5 Jul 2012, leledumbo wrote: I would like to document some of the FCL, however the layout is still like the first time it appears in FPC. Current FCL are splitted into many subpackages, and since the number of units is HUGE (which I guess the same reason why the package was splitted) would it be better to split the documentation as well? No, it's better to keep it together: 1. to have an overview of what is available. 2. cross-referencing across packages in documentation is not easy. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Unhandled exception from library crashes host exe
On Wed, 27 Jun 2012, Antonio Fortuny wrote: Le 27/06/2012 15:58, kyan a écrit : I am sure that this has been asked before but I couldn't find an answer. I am in the process of porting a large application consisting of an exe and many dlls from Delphi7 to FPC 2.7.1/Lazarus for Windows/WinCE with hopes of being able to finally port it to Linux. I have managed to overcome all obstacles but this seems like a brick wall: An exception raised from a dll that is not handled by the dll's code will crash the exe, bypassing any try/finally/except handlers around the call into the dll that raised it. This is of course a complete showstopper because the API and code of the dlls is way too massive to re-engineer so that it does not let exceptions bubble up to the exe. Got the same with UDFs for FIrebird. Read two Firebird bugs: http://62.166.198.202/view.php?id=12974 and http://62.166.198.202/view.php?id=17280 they appear to be intimately related. That will not help. The problem described there appears only on Win64. Not on Windows 32 or linux. I suspect the problem will not appear on Linux because the library system is slightly different to windows; but Win32, I am not sure. I am not sure the problem can be solved correctly with the compiler as-is, but the compiler people should confirm or deny this. Michael.___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Windows Phone 8 + pascal
On Mon, 25 Jun 2012, Sven Barth wrote: Am 24.06.2012 22:59 schrieb Juha Manninen juha.mannine...@gmail.com: On Sun, Jun 24, 2012 at 8:57 PM, Sven Barth pascaldra...@googlemail.com wrote: I believe they'll mostly go through the WinRT, which is Microsoft's new API pet project. Thanks. I didn't even know about this WinRT. New technologies are appearing all the time. Page http://en.wikipedia.org/wiki/Windows_RunTime says that WinRT is a COM-based API and uses a .NET-like metadata format. So it is not native code after all then. I don't know why they advertised it as native. I guess it is faster than .NET code because it is not managed. I thought that .NET allows non-managed code, too. Why does COM-based + .NET-like metadata imply that it's not native code? The core libraries are written in either C or C++ and the metadata is needed so that runtimes like .NET and languages like JavaScript can interface with WinRT. We can also use this metadata to generate Object Pascal wrappers (it is basically the successor of IDL which was used for interface definitions in the original COM) Well, now we know what you will do during your holidays ;-) I can't believe they invented yet another technology/API. Their partners must go crazy :/ Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Windows Phone 8 + pascal
On Mon, 25 Jun 2012, Sven Barth wrote: it as native. I guess it is faster than .NET code because it is not managed. I thought that .NET allows non-managed code, too. Why does COM-based + .NET-like metadata imply that it's not native code? The core libraries are written in either C or C++ and the metadata is needed so that runtimes like .NET and languages like JavaScript can interface with WinRT. We can also use this metadata to generate Object Pascal wrappers (it is basically the successor of IDL which was used for interface definitions in the original COM) Well, now we know what you will do during your holidays ;-) Ehm... no, not really. I see no reason in working on something that I don't plan to use. ;) I was not being serious. But it does seem something up your alley. I can't believe they invented yet another technology/API. Their partners must go crazy :/ They have seen that their pure managed approach on Windows Phone 7 wasn't as successful as thought and now they try to attract native, managed and web (JavaScript) developers... Could be. The end result is that they have now several technologies, and the new developer is faced with the choice: which one ? if you're in it for the long term, this is a crucial decision. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Adding method dynamically to a class
On Wed, 20 Jun 2012, ik wrote: On Wed, Jun 20, 2012 at 8:33 AM, LacaK la...@zoznam.sk wrote: ** Class helpers would not help ? http://wiki.freepascal.org/Helper_types They can, but there is a protocol that I'm trying to create that provides me information what to execute (out of white list). The thing is, that the first request maps the methods to be used, and there could be 2 or 200. To implement 200 methods that might be used is not a good idea imho, but adding the proper method to the instance/class will work much better. I don't understand this argument. The available methods must have an implementation somewhere anyway. That means your code does not get smaller by adding them dynamically. Somewhere you must choose which method to execute, and whether it is allowed or not, so this logic must be present also. None of this requires dynamically adding methods as far as I can see, or is made easier by dynamically adding methods. So finally, what is gained by adding them dynamically ? Or what forces you to even consider this path ? Michael ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Adding method dynamically to a class
On Wed, 20 Jun 2012, ik wrote: On Wed, Jun 20, 2012 at 10:20 AM, michael.vancann...@wisa.be wrote: On Wed, 20 Jun 2012, ik wrote: On Wed, Jun 20, 2012 at 8:33 AM, LacaK la...@zoznam.sk wrote: ** Class helpers would not help ? http://wiki.freepascal.org/**Helper_typeshttp://wiki.freepascal.org/Helper_types They can, but there is a protocol that I'm trying to create that provides me information what to execute (out of white list). The thing is, that the first request maps the methods to be used, and there could be 2 or 200. To implement 200 methods that might be used is not a good idea imho, but adding the proper method to the instance/class will work much better. I don't understand this argument. The available methods must have an implementation somewhere anyway. That means your code does not get smaller by adding them dynamically. Somewhere you must choose which method to execute, and whether it is allowed or not, so this logic must be present also. None of this requires dynamically adding methods as far as I can see, or is made easier by dynamically adding methods. So finally, what is gained by adding them dynamically ? Or what forces you to even consider this path ? Think of a plug-able system. I have an engine, and code to execute. Instead of compile everything to an ELF/PE, I place code on dynamic shard library, and load it on run time when needed. The idea is that the engine will not be rewritten for every new request (that comes often), because it's logic (almost) never changes, but to load code on demand that often changes, provide additional functions, changes of logic, bug fixes etc... The idea of implementing it like so, came to me after few years now of having the need to recreate the whole logic based of the code for every new demand from the client (both as human, and as software). The main code almost never changes, but so many additions, that I'm starting to use the dynamic execution of methods, and now I realize, that if I'll extract it to a shard library, it will be much easier to change, add etc... only the actual need, and not to touch other stuff, and that requires me to design an engine instead. This is understandable, but none of this explains why you would need to add a method to a class ? I have a similar system, but do not need to add methods to a class ? Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Adding method dynamically to a class
On Tue, 19 Jun 2012, ik wrote: Hello, Is there a way to tell in run-time that a specific function/procedure should belong to a class ? For example, let's say I have the following class: Type TTest = class procedure Foo; end; And I have also: procedure Bar; ... end; Is there a way to make at some point of my code execution, that Bar will be a method of TTest ? Or maybe for a specific instance of TTest ? As far as I know there is no language structure for this, unless the objective C classes support offers this. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Playing sounds with standard components
On Tue, 12 Jun 2012, Reinier Olislagers wrote: On 9-6-2012 23:18, Jorge Aldo G. de F. Junior wrote: You can use OpenAL or SDL... Found a framework that apparently uses SDL. Says it plays OGG and WAV. Haven't tried it.. https://github.com/freezedev/elysion SDL is so easy, it's hardly necessary to create a wrapper. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] fpimage blur
On Thu, 31 May 2012, Mattias Gaertner wrote: Hi, Is there a function to blur an entire fpimage or a rectangular area? Not to my knowledge. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] InstantFPC and argv
On Fri, 4 May 2012, dhkblas...@zeelandnet.nl wrote:
I'm creating a script to be executed by instantfpc when I noticed
that paramstr(0) does not reflect the location of the script but the
location of the cached executable. Is there a way to alter this location
programatically to the script location? Is there an alternative way?
The solution can be found on
http://www.freepascal.org/docs-html/prog/progsu38.html
Const
ScriptName = {$INCLUDE FILE};
Michael.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] InstantFPC and argv
On Fri, 4 May 2012, michael.vancann...@wisa.be wrote:
On Fri, 4 May 2012, dhkblas...@zeelandnet.nl wrote:
I'm creating a script to be executed by instantfpc when I noticed
that paramstr(0) does not reflect the location of the script but the
location of the cached executable. Is there a way to alter this location
programatically to the script location? Is there an alternative way?
The solution can be found on
http://www.freepascal.org/docs-html/prog/progsu38.html
Const
ScriptName = {$INCLUDE FILE};
Come to think of it, probably not 100% what you want.
It will contain the name of the temporary script file.
Michael.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] SQLDB: logging all generated SQL?
On Thu, 26 Apr 2012, Reinier Olislagers wrote: Good morning list, I vaguely remember somebody mentioning SQLDB has the option of dumping to a log all the SQL it sends to the database (in other words: logging all SQL sent to the database). Can somebody tell me if that functionality is there and where to find it? Perhaps something to do with TSQLConnection.LogEvents? That's the one. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Compiling from and to memory
On Thu, 19 Apr 2012, OBones wrote: Hello all, I'm currently creating a build chain where FPC is the last step, the one producing a DLL for Windows, x86 and x64. In front of it in the chain, I have designed a generator that creates a program and a set of units from its own representation. Right now, the program and units are written to disk and then FPC is called on those files. This works fine but is somewhat slow because of disk writing and reading. I was thus wondering if there was a way to send the program and unit contents directly to FPC without writing to disk, and then get FPC to output the final DLL to a memory location as well. The last part is optional, being able to send the program and units without disk access would be a nice thing. I looked around in the documentation for standard input, pipe, but apart from ways to access them from within a program, I was not able to find any information. Is this possible? If yes, how should I proceed? It is currently not possible. FPC always reads from and writes to files. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: RE : RE : Re: SQLDB GetSchemaInfoSQL for indexes etc?
On Thu, 19 Apr 2012, Reinier Olislagers wrote: On 19-4-2012 15:02, Ludo Brands wrote: Ludo here I do not understand what do you want to say. may be, that my english is not so good ;-) Can you explain please what is your proposal regarding to stIndexes ? stIndexes is currently not implemented: keep it that way (or drop it) but add and implement stTableConstraints, stReferentialConstraints, stKeyColumnUsage, stConstraintColumnUsage and stConstraintTableUsage. And why not some other missing information_schema views like 'views' or 'schemata'. Delphi compatibility? Delphi adodb defines and implements the following: type TSchemaInfo = (siAsserts, siCatalogs, siCharacterSets, siCollations, siColumns, siCheckConstraints, siConstraintColumnUsage, siConstraintTableUsage, siKeyColumnUsage, siReferentialConstraints, siTableConstraints, siColumnsDomainUsage, siIndexes, siColumnPrivileges, siTablePrivileges, siUsagePrivileges, siProcedures, siSchemata, siSQLLanguages, siStatistics, siTables, siTranslations, siProviderTypes, siViews, siViewColumnUsage, siViewTableUsage, siProcedureParameters, siForeignKeys, siPrimaryKeys, siProcedureColumns); Fine with Ludo's proposal; dropping stIndexes... and adding new ISO compliant stuff if needed. Delphi has at least adodb and dbexpress with various implementations so not much of a standard. Keeping to the information_schema standard seems like a good idea - especially because it will make it easier to easily get useful info from an ISO SQL 92+ compliant database.. Anybody against this? Michael? Joost? Not against. Has anybody used this functionality in sqldb at all? No. For a simple reason: I implemented all this information in fpdatadict; I think it belongs more there, and definitely not in the basic data API. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: RE : RE : Re: SQLDB GetSchemaInfoSQL for indexes etc?
On Thu, 19 Apr 2012, Reinier Olislagers wrote: On 19-4-2012 15:37, michael.vancann...@wisa.be wrote: On Thu, 19 Apr 2012, Reinier Olislagers wrote: On 19-4-2012 15:02, Ludo Brands wrote: Ludo here I do not understand what do you want to say. may be, that my english is not so good ;-) Can you explain please what is your proposal regarding to stIndexes ? stIndexes is currently not implemented: keep it that way (or drop it) but add and implement stTableConstraints, stReferentialConstraints, stKeyColumnUsage, stConstraintColumnUsage and stConstraintTableUsage. And why not some other missing information_schema views like 'views' or 'schemata'. Delphi compatibility? Delphi adodb defines and implements the following: type TSchemaInfo = (siAsserts, siCatalogs, siCharacterSets, siCollations, siColumns, siCheckConstraints, siConstraintColumnUsage, siConstraintTableUsage, siKeyColumnUsage, siReferentialConstraints, siTableConstraints, siColumnsDomainUsage, siIndexes, siColumnPrivileges, siTablePrivileges, siUsagePrivileges, siProcedures, siSchemata, siSQLLanguages, siStatistics, siTables, siTranslations, siProviderTypes, siViews, siViewColumnUsage, siViewTableUsage, siProcedureParameters, siForeignKeys, siPrimaryKeys, siProcedureColumns); Fine with Ludo's proposal; dropping stIndexes... and adding new ISO compliant stuff if needed. Delphi has at least adodb and dbexpress with various implementations so not much of a standard. Keeping to the information_schema standard seems like a good idea - especially because it will make it easier to easily get useful info from an ISO SQL 92+ compliant database.. Anybody against this? Michael? Joost? Not against. Has anybody used this functionality in sqldb at all? No. For a simple reason: I implemented all this information in fpdatadict; I think it belongs more there, and definitely not in the basic data API. I know you put stuff there... ATM there is some overlap between the two. I don't mind just leaving sqldb alone and just working with fpdatadict the fpdd* database specific code... but it's a good idea if we agree where/if we need to split things. This: I am trying to see if having a list of indexes in the database connectors would help with the data dictionary (packages\fcl-db\src\datadict)... It would help, yes. Michael. ... does confuse me a bit though. Could you tell me your thoughts on the way you see the split (if any)? It's a historic issue: I think fpdatadict was historically implemented first. It was implemented separately because I do not believe this belongs in sqldb. For instance, the data dictionary also supports DBF files. Obviously Joost thought otherwise, and started a parallel implementation in sqldb. I cannot undo that (unless Joost agrees, of course). Now, supposing it must remain in sqldb: I do not know if the calls for schema information will provide all info that datadict needs. If they do not, then I must re-implement them in datadict. If they do, then the default fpdatadict information retrieval routines can use the new schema calls. Unfortunately, it would take some time to investigate how much it overlaps. The bottom line is that I still think that this kind of info belongs in fpdatadict, which is broader in scope than sqldb (you could use it in zeos, for instance). But if it is available from sqldb, then fpdatadict can of course reuse that. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: RE : [fpc-pascal] Re: RE : RE : Re: SQLDB GetSchemaInfoSQL for indexesetc?
On Thu, 19 Apr 2012, Ludo Brands wrote: Has anybody used this functionality in sqldb at all? No. For a simple reason: I implemented all this information in fpdatadict; I think it belongs more there, and definitely not in the basic data API. Some of the metadata are necessary in the basic data API (tables, columns, indices) and are a partial overlap with the TFPDDEngine descendants. From an abstraction perspective, I think it is better to have database specifics as much as possible in one location and use standards as much as possible when specifying metadata. To be honest, I just discovered fpdatadict. Probably the missing implementation of a lot of the databases is one of the reasons why I haven't noticed it before. First impression is that the fpdatadict implementation makes sense but unfortunately the properties used are perhaps close to one particular database but are insufficient or confusing for other databases (no reference to schema or catalog, NUMERIC_SCALE, length vs. octet_length, collation,...). The data dictionary is an extension of what existed in the BDE times in Borland. It also featured a data dictionary but for some reason, Borland abandonded it (never understood why, as it is a good idea). This explains why it uses in large part that terminology. Other parts are based on firebird terminology for the simple reason that I use that database for all my projects. Even the database diff is in production use. As for re-using existing terminology (schema data etc.), this is dangerous as it creates the expectation that the implementation conforms to a certain standard, which is what I want to avoid. (I don't believe I've ever used the word schema in connection to a database. I think of an electrical wiring blueprint if I hear that word ;) ) But adding some aliases and add new features such as octet_length should not be a problem (NUMERIC_SCALE exists in precision). Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: RE : RE : Re: SQLDB GetSchemaInfoSQL for indexes etc?
On Thu, 19 Apr 2012, Reinier Olislagers wrote: Proposal 1. As I'm interested in getting support for MS SQL Server and Sybase ASE into lazdatadesktop, I propose I'll go on with trying to make that work using the current sqldb structure. This will mean that a lot of code will go into new datadict fpddmssql.pp and fpddsybase.pp modules. I'll submit patches when done. 2. With that experience, I might have a better idea whether extending/changing sqldb with ISO information_schema could easily work for datadict however, I must say your argument re other db adapters does make a lot of sense. If so, I'll convert lazdatadesktop and the mssqlconn sqldb connector, breaking compatibility. Next, I'll convert Firebird sqldb to use the new approach. If those work and are acceptable, I can submit a patch for the other connectors (Oracle, PostgreSQL, mysql)... but will probably need some support for that. If not, I can try and adapt fpdatadict.pp and their dependents to use information_schema calls in e.g. ImportIndexes in order to make a default implementation for ISO compatible RDBMS... which non-compatible sqldb/dbf/zeos/whatever dbs will override... I will just ignore sqldb; perhaps provide a patch for mssqlconn to at least let it spit out similar info as Firebird. What do you guys think? I expect your patches on Monday :-) Seriously: please go ahead. If you need help, just mail me. I'll be glad to see fpdatadict support more engines; Maybe it will gain wider acceptance, and the same then for the lazarus data database desktop. I use it daily, but then, I use firebird... Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: RE : RE : [fpc-pascal] Re: RE : RE : Re: SQLDB GetSchemaInfoSQL forindexesetc?
On Thu, 19 Apr 2012, Ludo Brands wrote: But adding some aliases and add new features such as octet_length should not be a problem (NUMERIC_SCALE exists in precision). And where exist NUMERIC_PRECISION then? This is used in databases like Oracle that use numerics. A number(10,4) has precision 10 and scale 4, radix 10. fpdatadict uses the same name as the TField properties. Size=4, Precision = 10. Property Size : Integer Read FSize Write FSize Stored IsSizeStored; Property Precision : Integer Read FPrecision Write FPrecision Stored IsPrecisionStored; I agree that the names are confusing, but I blame Borland employees for that ;-) Like I said: adding some aliases should take care of this. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: RE : RE : [fpc-pascal] Re: RE : RE : Re: SQLDB GetSchemaInfoSQL forindexesetc?
On Thu, 19 Apr 2012, Ludo Brands wrote: As for re-using existing terminology (schema data etc.), this is dangerous as it creates the expectation that the implementation conforms to a certain standard, which is what I want to avoid. (I don't believe I've ever used the word schema in connection to a database. I think of an electrical wiring blueprint if I hear that word ;) ) There are other databases (mssql, oracle) where it is difficult to not use schemas. So even when not using the word 'schema' the concept should be represented somewhere. Ehm, the datadictionary is the schema ? Unless I misunderstand the meaning of schema :-) Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] SQLDB GetSchemaInfoSQL for indexes etc?
On Tue, 17 Apr 2012, Reinier Olislagers wrote: In sqldb, this: type TSchemaType = (stNoSchema, stTables, stSysTables, stProcedures, stColumns, stProcedureParams, stIndexes, stPackages); is used in the GetSchemaInfoSQL function: I noticed stIndexes, stProcedureParams and stPackages do not seem to be used in the current sqldb connectors in packages\fcl-db\src\sqldb\ and below. The others are used in GetSchemaInfoSQL to get an SQL command that returns the names of the objects (tables etc): e.g. tables: Firebird: s := 'select '+ 'rdb$relation_id as recno, '+ + DatabaseName + ''' as catalog_name, '+ ' as schema_name, '+ 'rdb$relation_nameas table_name, '+ '0as table_type '+ 'from '+ 'rdb$relations '+ 'where '+ '(rdb$system_flag = 0 or rdb$system_flag is null) ' + // and rdb$view_blr is null 'order by rdb$relation_name'; MS SQL Server: Result := format(SCHEMA_QUERY, ['table_name','U']); Does anybody know what stIndexes, stProcedureParams and stPackages should return and when they would be used? stIndexes: get a list of indexes from a table. stPRocedureParams: get the parameters of a stored procedure stPackages: list packages (Oracle and Firebird) What happens e.g. with indexes - that IIRC can have unique names per database (Firebird,...) or per table (MS SQL Server,...)? I am trying to see if having a list of indexes in the database connectors would help with the data dictionary (packages\fcl-db\src\datadict)... It would help, yes. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: SQLDB GetSchemaInfoSQL for indexes etc?
On Tue, 17 Apr 2012, Reinier Olislagers wrote: On 17-4-2012 10:36, Reinier Olislagers wrote: In sqldb, this: type TSchemaType = (stNoSchema, stTables, stSysTables, stProcedures, stColumns, stProcedureParams, stIndexes, stPackages); is used in the GetSchemaInfoSQL function: I noticed stIndexes, stProcedureParams and stPackages do not seem to be used in the current sqldb connectors in packages\fcl-db\src\sqldb\ and below. The others are used in GetSchemaInfoSQL to get an SQL command that returns the names of the objects (tables etc): e.g. tables: Firebird: s := 'select '+ 'rdb$relation_id as recno, '+ + DatabaseName + ''' as catalog_name, '+ ' as schema_name, '+ 'rdb$relation_nameas table_name, '+ '0as table_type '+ 'from '+ 'rdb$relations '+ 'where '+ '(rdb$system_flag = 0 or rdb$system_flag is null) ' + // and rdb$view_blr is null 'order by rdb$relation_name'; MS SQL Server: const SCHEMA_QUERY='select name as %s from sysobjects where type=''%s'' order by 1'; Result := format(SCHEMA_QUERY, ['table_name','U']); PostgreSQL: stTables : s := 'select '+ 'relfilenode as recno, '+ + DatabaseName + ''' as catalog_name, '+ ' as schema_name, '+ 'relname as table_name, '+ '0as table_type '+ 'from '+ 'pg_class '+ 'where '+ '(relowner 1) and relkind=''r''' + 'order by relname'; Ooops, comparing these, it seems there is some kind of standard result set that the MSSQL Connector does not follow as it returns only a single name column. I'll update the mssqlconn connector when I get to it. Is there any further documentation on the required output, e.g. the table_type? recno presumably is unique id, catalog_name, schema_name are presumably ISO catalog/schema, table_name is the name of the table. Presumably, yes. Joost should be able to answer these questions in more detail. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] CGI under Linux using FCL-Web
On Wed, 4 Apr 2012, Leonardo M. Ramé wrote: Another tip for linux/unix. Try to run the CGI program from the command line, it should output something similar to this: Exception at 00497B3A: Exception: No REQUEST_METHOD passed from server. Otherwise there's an error in your code. Better yet, you can test CGI programs with the testcgiapp program that is located in the fcl-web sources. developed specially to test such things. Michael. Leonardo M. Ramé http://leonardorame.blogspot.com From: michael.vancann...@wisa.be michael.vancann...@wisa.be To: FPC-Pascal users discussions fpc-pascal@lists.freepascal.org Sent: Wednesday, April 4, 2012 8:42 AM Subject: Re: [fpc-pascal] CGI under Linux using FCL-Web On Wed, 4 Apr 2012, Christian Kranich wrote: Hello All, I just started to use FPC in a project requiring a Webinterface. When porting the Lazarus/Win32 fpc-web examples (worked fine) to X86/Linux(Ubuntu) and Arm-Linux, I started to struggle. Under Linux, the cgi program terminates w/o any output and w/o any errormessages. So Apache complains about premature page end. = Is there anything special to consider when using fcl-web under Linux? Yes. * Do not use the crt, video or keyboard units. * Do not attempt I/O to standard input/output/error. = The bread and butter cgi example (mini.pas) did run, but I like the concept of FCL-Web offering scalability between CGI, FastCGI, Apache Module and do not want to reinvent the wheel... Currently I started copying the fcl-web sources to project folder and pinpointing with writelns to crosscheck what is running and what is not. Check the error log of apache. It will contain the error output of the CGI script. 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 ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: CGI under Linux using FCL-Web
On Wed, 4 Apr 2012, Christian Kranich wrote: Hello All, 1) Sorry, I posted no follow ups but fress posts (twice) before noticing. Will not repeat this. 2) just tried testcgiapp --input=mycgi.cgi This also returns silently w/o any other output. The path to the htmls is also valid. Where and how is the CGI input processed? I see only a TFPWebmodule type object in my code (and the DataModuleRequest method to handle the request..) and a RegisterHTTPModule() in the main of the program. Is there anything that I need to initialize(which might be done correctly under Windows but needs an extra step under Linux)? You need to fill DataModuleRequest with code; It should put something in response, and then call Response.SendResponse. If you don't, nothing will happen. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Re: [Lazarus] Library with XMLHttpRequest functionality?
On Tue, 3 Apr 2012, Frank Church wrote: Is there some library in FPC/Lazarus which implements XMLHTTPRequest functionality? XMLHTTPRequest is just a regular HTTP request. You can use the TFPHTTPClient component for it. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Fileread function (leledumbo)
On Mon, 2 Apr 2012, Luis Fernando Del Aguila Mejía wrote: El 02/04/2012 05:00 a.m., fpc-pascal-requ...@lists.freepascal.org escribió: Do you mean if FileRead executed when the file pointer is at the end of file, it would wrap around to the beginning? Yes, it is possible? Example, is it correct?: FileWrite(Arch,b,40); // Write 40 bytes FileRead(Arch,b,40); //Read 40 bytes This is not possible. or, is this correct?: FileWrite(Arch,b,40); // Write 40 bytes Fileseek(Arch,0,fsFromBeginning)); //Move to begining FileRead(Arch,b,40); //Read 40 bytes This is correct. Michael.___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: How to handle SIGPIPE
On Tue, 20 Mar 2012, Tobias Giesen wrote: Hi, I think the biggest issue is that MSG_NOSIGNAL is not defined on MAC OS, even though it was added a few years (?) ago. When I ported Synapse, unfortunately I defined it as 0. Now I changed that to $2 and I'm hoping for the best ... I also added this to my program, is that correct? At first sight: yes. Michael. var NewSigRecSigActionRec; res:Integer; initialization with NewSigRec do begin Integer(@Sa_Handler):=SIG_IGN; // ignore signal Sa_Mask[0]:=0; Sa_Flags:=0; end; res:=fpsigaction(SIGPIPE,@NewSigRec,@OldSigRec); Cheers, Tobias ___ 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] fpWeb: Error when trying to call a module without an action
On Fri, 9 Mar 2012, michael.vancann...@wisa.be wrote: On Fri, 9 Mar 2012, Sven Barth wrote: I'm using the embedded webserver variant and the error only surfaced after I added a second module which let's me assume that the problem is the same as this: http://lists.lazarus.freepascal.org/pipermail/lazarus/2011-June/063655.html And what exactly is the problem ? You can set the default module name in the TFPWebApplication. But in that case, the path is interpreted as the action to execute, so the correct URL would be http://localhost:4321/list to have the module first requires an additional property and patch. This is planned. I implemented the 'PreferModuleName' property in TWebHandler and TFPCustWebApplication in rev. 20495. if set to True, then the URL http://localhost:4321/treenode/ will select the 'treenode' module. Default for the new property is currently 'False', which is backwards compatible. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] fpWeb: Error when trying to call a module without an action
On Fri, 9 Mar 2012, Sven Barth wrote: Hello together! As I already said on fpc-devel I'm currently playing around with fcl-web and hit the next problem: I successfully managed to build and run my first module, but when I added a second one I got an error when I use the following URL to call my module (of which one is registered as treenode): http://localhost:4321/treenode The given error is: Could not determine HTTP module for request It works correctly if I supply the name of the default action list (or any other registered action). E.g. the following returns the desired content: http://localhost:4321/treenode/list I'm using the embedded webserver variant and the error only surfaced after I added a second module which let's me assume that the problem is the same as this: http://lists.lazarus.freepascal.org/pipermail/lazarus/2011-June/063655.html And what exactly is the problem ? You can set the default module name in the TFPWebApplication. But in that case, the path is interpreted as the action to execute, so the correct URL would be http://localhost:4321/list to have the module first requires an additional property and patch. This is planned. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Trim(): incompatibility with Delphi
On Mon, 5 Mar 2012, Bart wrote:
Hi,
Brought up in Lazarus forums.
Fpc Trim(): Trim whitespace from the ends of a string.
Delphi Trim(): Trims leading and trailing spaces and control
characters from a string.
Depends on what you mean by whitespace, of course.
FPC strips everything below Ord(' '), and thus should behave the same as Delphi.
Michael.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Currency and ABS(-674.59)
On Tue, 6 Mar 2012, Zaher Dirkey wrote: On Mon, Mar 5, 2012 at 12:22 AM, Jonas Maebe jonas.ma...@elis.ugent.bewrote: This particular problem could obviously be resolved by adding a currency-specific version of abs() Can i ask to add overload function for ABS(Currency) be a feature request in FPC? Yes, please add an entry in the bugtracker. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Currency and ABS(-674.59)
On Tue, 6 Mar 2012, Jonas Maebe wrote: On 06 Mar 2012, at 13:05, michael.vancann...@wisa.be wrote: On Tue, 6 Mar 2012, Zaher Dirkey wrote: On Mon, Mar 5, 2012 at 12:22 AM, Jonas Maebe jonas.ma...@elis.ugent.bewrote: This particular problem could obviously be resolved by adding a currency-specific version of abs() Can i ask to add overload function for ABS(Currency) be a feature request in FPC? Yes, please add an entry in the bugtracker. Note that this requires compiler patching, because abs() is internal (it can be used in constant expressions). I would personally argue to do away entirely with the treat currency as a floating point type on i386 so it can use the 80x87, and instead map it implementation-wise to int64 like on all other platforms. You may lose a bit of performance, but you'll gain consistency. And you won't need hacks like this (which, as mentioned before, only solves one particular use-case, and so I'm not very much in favour of doing this). As far as I know, Currency is always a scaled int64, and didn't interpret the request as a request to change that. I missed probably part of the argumentation but on the face of it, having a ABS(Currency) seems like a reasonable request. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Variant vs Pointer
On Fri, 2 Mar 2012, Marcos Douglas wrote: On Wed, Feb 29, 2012 at 10:38 PM, Marcos Douglas m...@delfire.net wrote: Hi, The TField class have the FValueBuffer: Pointer attribute and have also SetData(Buffer: Pointer,...) method that all T***Field subclasses use to set themselves. The methods AsInteger, AsString, etc use FValueBuffer to convert in an especific type. So, FValueBuffer could be anything. My question is: What would be the difference in performance if FValueBuffer were a Variant type? Marcos Douglas Nobody knows? I need implements a similar structure but I need know if the use of Variant have very cost. It has a cost. The reason for using a buffer in tdataset is that a record's data normally is located in one continuous buffer, from which a value is picked from the right spot (including strings) You can't have that with variants. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Where and how is the FPC documentation created?
On Thu, 1 Mar 2012, Frank Church wrote: On 29 February 2012 19:52, Michael Van Canneyt mich...@freepascal.orgwrote: On Wed, 29 Feb 2012, Reinier Olislagers wrote: On 29-2-2012 17:07, michael.vancanneyt-**0is9kj9s...@public.gmane.orgmichael.vancanneyt-0is9kj9s...@public.gmane.orgwrote: On Wed, 29 Feb 2012, Frank Church wrote: Another question, are you and Florian Klaempfl the main or only contributors? I am virtually the only one, but I do receive and apply minor patches from time to time. *Cough* http://bugs.freepascal.org/**view.php?id=20735http://bugs.freepascal.org/view.php?id=20735 *cough* I'd love to see that patch committed or get some feedback on it ;) oh :/ I tried it at once when you submitted it. But there were quite some errors in the XML, which is why I left it for later... and eventually forgot about it :( My apologies for this. I now corrected the XML and committed it. Rev 892. Thank you for the contribution ! Michael. __**_ fpc-pascal maillist - fpc-pascal@lists.freepascal.**orgfpc-pascal@lists.freepascal.org http://lists.freepascal.org/**mailman/listinfo/fpc-pascalhttp://lists.freepascal.org/mailman/listinfo/fpc-pascal Isn't this an example of what is considered wrong with the FPC/Lazarus processes? Absolutely not. At the very least if Reinier did not have the rights to commit, he should have had a duplicate set of the tools Michael used to check of the correctness of the file (assuming that it was not visually inspected). If there was some automated system capable of checking the file's syntax and accepting it, Reinier would have known straight away and fixed it He has all the needed tools and he should have done so prior to submitting. That he did not check before submitting is not an error in the system, but his mistake. That I didn't notify him of the errors when I first checked, is my mistake. immediately. Others who have registered an interest in that topic would also have been automatically emailed then they could review the correctness and quality of the contents etc. Perhaps they exist and I and a lot of others don't know about them. At this stage it doesn't look like Reinier knows what the flaws in the file he submitted are, unless he diffs what Michael committed against what he submitted He could perfectly have run fpdoc on the file. The command fpdoc --package=fcl --input=ibconnection.pp --descr=ibconnection.xml --output=latex would have given him all the info he needs. The standalone editor can construct and run this command for you, if I'm correct. The Makefiles contain lots of examples, waiting to be consulted. And all this is documented in official docs on the Free Pascal website. What more can people want ? Imagine what happens when more and more people submit docs and the extra work for the few people with commit rights. Everyone on the FPC/lazarus teams has commit rights. It's just like regular submissions. There is also one thing. The documentation of the libraries and the compiler proper are different issues. In the case of the libraries shouldn't those who create them have commit rights in that area assuming that they have the tools to check the syntactic correctness of their submissions? But they do. But this doesn't help in this particular case. Reinier didn't create the ibconnection unit; He has no SVN access to anything. I assume he uses the unit, and therefor decided to document it. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
