Re: [fpc-pascal] GetTableNames in TSQLConnection / Postgresql
On 16-12-2012 2:27, John wrote: @Reinier: Analysis: As far as I can work out, a call to GetTableNames calls GetDBInfo, with parameters ASchemaType : TSchemaType - This specifies what info we want - user tables, sys tables, procedures, columns etc ASchemaObjectName - Doesn't seem to be used, it is specified as No, it's not used for GetTableNames; it is used e.g. to specify the table name if you want to know info about columns. Yes, I saw that, but there seems no reason why it could not be used as a schema selection. I understand; just wanted to let you know what it was used for. I also had a flip through the previous discussion, but it was indeed a long and tortuous thread to follow! Agreed. AFAIR, there was a decision in the end... but it was a long thread and a long while ago. I've incorporated some of Lacak's proposal into http://wiki.lazarus.freepascal.org/Database_metadata#Proposal_for_extension.2Funiformization ... and will update that page going through that thread. If anybody gets to it earlier, please feel free to update the page ;) So the question comes back to how should the table names be returned ? Indeed, is there a specification for what should be returned for all of these metadata queries ? AFAIR, there is no single spec as there are multiple examples we can draw from (ODBC, JDBC, Delphi ADO etc) IIRC, that thread did have a decision in the end though on what everybody agreed was a good proposal. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] How do FreePascal implement hardware exceptions handling?
I analyze FreePascal exceptions handling. Instead use of try-excpt-finally statement I rather use fpc_LongJmp,fpc_PushExceptAddr etc. It works fine for software exceptions (fpc_RaiseException) but not handle hardware exceptions. I use install_exception_handlers at start program. This call SetUnhandledExceptionFilter(@syswin32_i386_exception_handler) but is problem: in syswin32_i386_exception_handler is comparing if excep^.ContextRecord^.SegSs = _SS then - _SS is correct stack segment but excep^.ContextRecord^.SegSs - no, it is a different value, why? I can attach my files best, Andrzej Borucki ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] How do FreePascal implement hardware exceptions handling?
On 15.12.2012 18:40, Andrzej Borucki wrote: I analyze FreePascal exceptions handling. Instead use of try-excpt-finally statement I rather use fpc_LongJmp,fpc_PushExceptAddr etc. It works fine for software exceptions (fpc_RaiseException) but not handle hardware exceptions. FPC relies on the hardware exception support provided by the operating system. For Windows this is accomplished by using SetUnhandledExceptionFilter (or using SEH on Windows 64 if the compiler is compiled with the correct define) while on Unix this means that signals like SIGSEGV or SIGFPE are hooked. It is not recommended to use fpc_LongJmp, fpc_PushExceptAddr etc. manually as FPC's code generation could interfere with your intentions here (note: the correct way of using longjmp would be by using the function LongJmp instead of fpc_LongJmp (and likewise SetJmp instead of fpc_SetJmp). So: why are you doing this? I use install_exception_handlers at start program. This call SetUnhandledExceptionFilter(@syswin32_i386_exception_handler) but is problem: in syswin32_i386_exception_handler is comparing if excep^.ContextRecord^.SegSs = _SS then - _SS is correct stack segment but excep^.ContextRecord^.SegSs - no, it is a different value, why? I can attach my files Why are you doing this? install_exception_handlers is called during process entry of Win32/Win64 programs already, so calling this twice can be considered a bad(TM) idea. Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] GetTableNames in TSQLConnection / Postgresql
On 12/16/2012 07:08 PM, Reinier Olislagers wrote: I've incorporated some of Lacak's proposal into http://wiki.lazarus.freepascal.org/Database_metadata#Proposal_for_extension.2Funiformization ... and will update that page going through that thread. If anybody gets to it earlier, please feel free to update the page ;) Which ignores the question I asked previously as to how you separate the system tables from the user tables ... But I think I understand our different views a bit better now - you are looking at this from the point of view of simply getting the SQL and running it in a separate query ? Is this so ? Whereas I was specifically wanting to fix the TSQLConnection.GetTableNames. GetTableNames in its current form cannot benefit from adding the schema column into the query (or rather, getting it to work) as it only uses data from one column. Anyway, it sounds like for now at least I had better just go down the path of deriving my own tPQConnection descendant. cheers, John Sunderland ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Feature announcement: Generic type constraints
Hello Free Pascal community!
I'm pleased to announce the addition of generic type constraints to Free
Pascal (beginning from revision 23158).
Overview:
Generic type constraints allow to restrict the set of possible types
that can be used to specialize a given generic. So for example one can
restrict a type parameter to only allow descendants of a given class
type that implement a specific interface.
Syntax:
A type parameter declaration now looks like this: a set of comma
seperated generic parameter names is either followed by a ; or a :.
If the former than another list of generic type parameters follows.
Otherwise after the : follows a comma seperated list of the following
constraints:
- record
- class
- a class identifer
- an interface identifier
[- constructor (only allowed in mode Delphi; for the reason see
Delphi compatibility)]
After such a constraint list follows either a which means that this
is the last parameter list or a ; after which another list of generic
type parameters follows.
Semantics:
The rules for the above mentioned constraints are as follows:
- record can only be used by itself and is mutually exclusive to each
other constraint; only record types can be used to satisfy this constraint
- class can be used together with any other constraint except record
and a class identifier; it defines that the specialization type is a
class type that's either TObject or a descendant of it
- multiple interface identifiers can be used to denote interfaces that
the given identifier must implement; they are mutually exclusive to
record; giving multiple interfaces implicitly requires the
specialization parameter to be a class type; if only a single interface
is given the specialization type can be an interface derived from that
interface as well
- one class identifier can be given (mutually exclusive to class and
record) to denote that the specialization parameter must be either of
the given class type or a descendant of it
[- constructor is mutually exclusive to record and behaves like
class ]
The order of the constraints is not important.
Examples:
type
{ only class types deriving from TObject can be used }
generic TExample1T: class = class
end;
{ the same as the above with the exception that this is not valid
code in Delphi }
generic TExample2T: TObject = class
end;
{ the parameter must derive from a TStrings class; valid types are
for example TStrings or TStringList }
generic TExample3T: TStrings = class
end;
{ valid types are for example IInterface, IUnknown,
TInterfacedObject or basically anything that derives from TComponent
as that class implemnts IInterface as well }
generic TExample4T: IInterface = class
end;
{ unlike above interface types (IInterface, IUnknown, etc.) are
not valid here }
generic TExample5T: class, IInterface = class
end;
{ same as above; the order is not important }
generic TExample6T: IInterface, class = class
end;
{ a class that implements the two given interfaces though this does
not need to be the case on the same level; e.g. a class that derives
from TInterfacedObject that implements ISomeOtherInterface is valid
as well }
generic TExample7T: IInterface, ISomeOtherInterface = class
end;
{ the same as above; the class is redundant }
generic TExample8T: class, IInterface, ISomeOtherInterface = class
end;
{ the type must be a record }
generic TExample9T: record = class
end;
{ T1 must be a descendant of TObject while T2 can be of any type }
generic TExample10T1: class; T2 = class
end;
{ the inverse of the above: T1 can be any type while T2 needs to
be a descendant of TObject }
generic TExample11T1; T2: class = class
end;
{ T1 and T2 need to be a descendant of TStrings, T3 can be of
any type and T4 needs to be either a descendant of IInterface or a
descendant of a class that implements IInterface }
generic TExample12T1, T2: TStrings; T3; T4: IInterface = class
end;
Delphi compatibility:
The compiler can correctly handle Delphi compatible type constraints in
mode Delphi. It does not check though that the constraint : TObject is
not used which is not allowed in Delphi.
Also in mode Delphi the constraint constructor is available as well.
This constraint is not available in other modes because it is handled
rather strangely in Delphi and in concept behaves like a complicated
class constraint and is very likely a relict of Delphi.Net.
Delphi's behavior is as follows:
If the constructor constraint is not given (but e.g. class or class
identifier is) one can NOT call .Create on that type (even if the
constructor would need parameters). What is allowed however is to call a
constructor that is not named Create, e.g. constructor
CreateFromGeneric.
It would be understandable if the constructor constraint would require
the programmer to have a parameterless constructor Create defined in
the given class type, but the compiler
Re: [fpc-pascal] GetTableNames in TSQLConnection / Postgresql
On Sun, 16 Dec 2012, Reinier Olislagers wrote: On 16-12-2012 2:27, John wrote: @Reinier: Analysis: As far as I can work out, a call to GetTableNames calls GetDBInfo, with parameters ASchemaType : TSchemaType - This specifies what info we want - user tables, sys tables, procedures, columns etc ASchemaObjectName - Doesn't seem to be used, it is specified as No, it's not used for GetTableNames; it is used e.g. to specify the table name if you want to know info about columns. Yes, I saw that, but there seems no reason why it could not be used as a schema selection. I understand; just wanted to let you know what it was used for. I also had a flip through the previous discussion, but it was indeed a long and tortuous thread to follow! Agreed. AFAIR, there was a decision in the end... but it was a long thread and a long while ago. I've incorporated some of Lacak's proposal into http://wiki.lazarus.freepascal.org/Database_metadata#Proposal_for_extension.2Funiformization ... and will update that page going through that thread. If anybody gets to it earlier, please feel free to update the page ;) It would be good to add a link to the 'standard sql' referred to ? 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 16-12-2012 14:55, Michael Van Canneyt wrote: On Sun, 16 Dec 2012, Reinier Olislagers wrote: On 16-12-2012 2:27, John wrote: @Reinier: Analysis: As far as I can work out, a call to GetTableNames calls GetDBInfo, with parameters ASchemaType : TSchemaType - This specifies what info we want - user tables, sys tables, procedures, columns etc ASchemaObjectName - Doesn't seem to be used, it is specified as No, it's not used for GetTableNames; it is used e.g. to specify the table name if you want to know info about columns. Yes, I saw that, but there seems no reason why it could not be used as a schema selection. I understand; just wanted to let you know what it was used for. I also had a flip through the previous discussion, but it was indeed a long and tortuous thread to follow! Agreed. AFAIR, there was a decision in the end... but it was a long thread and a long while ago. I've incorporated some of Lacak's proposal into http://wiki.lazarus.freepascal.org/Database_metadata#Proposal_for_extension.2Funiformization ... and will update that page going through that thread. If anybody gets to it earlier, please feel free to update the page ;) It would be good to add a link to the 'standard sql' referred to ? The standard mentioned is the SQL ISO standard (e.g. the 2008 version). Draft versions are floating around the internet, but the official one you'd have to buy... Regards, Reinier ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] GetTableNames in TSQLConnection / Postgresql
On 16-12-2012 14:55, Michael Van Canneyt wrote: On Sun, 16 Dec 2012, Reinier Olislagers wrote: On 16-12-2012 2:27, John wrote: @Reinier: Analysis: As far as I can work out, a call to GetTableNames calls GetDBInfo, with parameters ASchemaType : TSchemaType - This specifies what info we want - user tables, sys tables, procedures, columns etc ASchemaObjectName - Doesn't seem to be used, it is specified as No, it's not used for GetTableNames; it is used e.g. to specify the table name if you want to know info about columns. Yes, I saw that, but there seems no reason why it could not be used as a schema selection. I understand; just wanted to let you know what it was used for. I also had a flip through the previous discussion, but it was indeed a long and tortuous thread to follow! Agreed. AFAIR, there was a decision in the end... but it was a long thread and a long while ago. I've incorporated some of Lacak's proposal into http://wiki.lazarus.freepascal.org/Database_metadata#Proposal_for_extension.2Funiformization ... and will update that page going through that thread. If anybody gets to it earlier, please feel free to update the page ;) It would be good to add a link to the 'standard sql' referred to ? Also, e.g. PostgreSQL and Mimer have very good documentation on what these information_schema views contain. I vaguely recall this was covered in our previous thread... ___ 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 15.12.2012 04:24, silvioprog wrote: More than 15,000 lines of source code, more than 90 test cases, more than one year of work. Today, a new framework for web development was born. It's name is Brook and its nice features are available for you. I thank the FPWeb, the Freespider, the Powtils, the ExtPascal, the CustCGI and the EazyCGI developers. I got inspiration in all of them and and still in Rails and Slim Framework. This sounds interesting. I'll evaluate your framework once I find the time to reimplement my website. :) A small note though: Here http://brookframework.org/get-started.html it should read If you are a Lazarus user instead of If you is a Lazarus user Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Re: Feature announcement: Generic type constraints
Wonderful, Sven! Now we could have an even better generics feature than Delphi or C++ (forget Java and .NET) -- View this message in context: http://free-pascal-general.1045716.n5.nabble.com/Feature-announcement-Generic-type-constraints-tp5712290p5712295.html Sent from the Free Pascal - General mailing list archive at Nabble.com. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Feature announcement: Generic type constraints
On 16.12.2012 18:00, leledumbo wrote: Wonderful, Sven! Now we could have an even better generics feature than Delphi or C++ (forget Java and .NET) Ehm... you know that AFAIK all those languages have constraints as well? :) Though if your comment is regarding the possible future developments: of course :D Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Indexing files
In our previous episode, Michael Van Canneyt said: The inotify calls are available on Linux. It tells you when a file/folder changes: function inotify_init: cint; function inotify_init1(flags:cint):cint; function inotify_add_watch(fd:cint; name:Pchar; mask:cuint32):cint; These calls are available in the linux unit. I have an article that describes how it works, if you want. There is a similar mechanism on windows, but I haven't had time to look at it yet: I wanted to make a unified architecture for this kind of things. I think Ales was at some point working on having a common kevent +inotify support unit. (Kevent is the OSX/BSD variant) ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Indexing files
On Sun, 16 Dec 2012, Marco van de Voort wrote: In our previous episode, Michael Van Canneyt said: The inotify calls are available on Linux. It tells you when a file/folder changes: function inotify_init: cint; function inotify_init1(flags:cint):cint; function inotify_add_watch(fd:cint; name:Pchar; mask:cuint32):cint; These calls are available in the linux unit. I have an article that describes how it works, if you want. There is a similar mechanism on windows, but I haven't had time to look at it yet: I wanted to make a unified architecture for this kind of things. I think Ales was at some point working on having a common kevent +inotify support unit. (Kevent is the OSX/BSD variant) Really ? Maybe it could be added to the fcl-base ? Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Indexing files
On 16 Dec 12, at 18:34, Michael Van Canneyt wrote: On Sun, 16 Dec 2012, Marco van de Voort wrote: In our previous episode, Michael Van Canneyt said: The inotify calls are available on Linux. It tells you when a file/folder changes: function inotify_init: cint; function inotify_init1(flags:cint):cint; function inotify_add_watch(fd:cint; name:Pchar; mask:cuint32):cint; These calls are available in the linux unit. I have an article that describes how it works, if you want. There is a similar mechanism on windows, but I haven't had time to look at it yet: I wanted to make a unified architecture for this kind of things. I think Ales was at some point working on having a common kevent +inotify support unit. (Kevent is the OSX/BSD variant) Really ? Maybe it could be added to the fcl-base ? If so, make sure to make it a separate unit and enable this unit in fpmake.pp for the supported targets only, because I don't think that such a functionality exists for OS/2 (not even mentioning other targets supporting fcl-base like go32v2)... Tomas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Indexing files
In our previous episode, Tomas Hajny said: I think Ales was at some point working on having a common kevent +inotify support unit. (Kevent is the OSX/BSD variant) Really ? Maybe it could be added to the fcl-base ? If so, make sure to make it a separate unit and enable this unit in fpmake.pp for the supported targets only, because I don't think that such a functionality exists for OS/2 (not even mentioning other targets supporting fcl-base like go32v2)... I think that was what it stalled on. Ales not wanting to abstract windows at that time. IMHO packages in FCL should at least support the core platforms. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Indexing files
On Sun, 16 Dec 2012, Marco van de Voort wrote: In our previous episode, Tomas Hajny said: I think Ales was at some point working on having a common kevent +inotify support unit. (Kevent is the OSX/BSD variant) Really ? Maybe it could be added to the fcl-base ? If so, make sure to make it a separate unit and enable this unit in fpmake.pp for the supported targets only, because I don't think that such a functionality exists for OS/2 (not even mentioning other targets supporting fcl-base like go32v2)... I think that was what it stalled on. Ales not wanting to abstract windows at that time. IMHO packages in FCL should at least support the core platforms. I will have a look at it. It's on my todo anyway. If Ales has a OSX/BSD variant, then that would be helpful. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Indexing files
And which database you prefer? I don't need complicated functionality. The most important is insert speed and it must be embedded. I'm thinking of SQLight, DBF or Firebird Embedded ___ 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
2012/12/16 Sven Barth pascaldra...@googlemail.com On 15.12.2012 04:24, silvioprog wrote: More than 15,000 lines of source code, more than 90 test cases, more than one year of work. Today, a new framework for web development was born. It's name is Brook and its nice features are available for you. I thank the FPWeb, the Freespider, the Powtils, the ExtPascal, the CustCGI and the EazyCGI developers. I got inspiration in all of them and and still in Rails and Slim Framework. This sounds interesting. I'll evaluate your framework once I find the time to reimplement my website. :) A small note though: Here http://brookframework.org/get-**started.htmlhttp://brookframework.org/get-started.htmlit should read If you are a Lazarus user instead of If you is a Lazarus user Regards, Sven Thank you very much Sven! I'm sure Brook will reply your expectations. :) And, your fix was applied: https://github.com/silvioprog/brook-site/commit/ca7a742cebcb95da99809506fd2a52a5ceb30eb5 -- Silvio Clécio My public projects - github.com/silvioprog ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Websocket client
Hi, Anyone know good and free websocket client which work on linux and windows? What I found: 1. http://code.google.com/p/bauglir-websocket - looks nice, based on synapse. But demo can't connect to ws://echo.websocket.org on port 8080. Seems that thread listener don't have exception handlers. I will try to add it and see what is a reason. Probably only host format error 2. Habari components - not free 3. http://asmprofiler.googlecode.com/svn/trunk/-Other-/IndyWebsocketDemo/ . Can't compile demo. Seems free but uses uROIndyHTTPServer unit which is a part of some not free package Regards ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Websocket client
At 12:32 PM 12/16/2012, Krzysztof wrote: Hi, Anyone know good and free websocket client which work on linux and windows? Have you looked at what is included into Francois Piette's ICS? (http://www.overbyte.be/frame_index.html?redirTo=/products/ics.html) Ralf ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Websocket client
Yes, I saw it in google result. What I remember that ICS was only for windows. Something changed in this case? ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Websocket client
At 01:14 PM 12/16/2012, Krzysztof wrote: Yes, I saw it in google result. What I remember that ICS was only for windows. Something changed in this case? No, not that I am aware of, it is AFAIK still Windows only. But then you did not mention that you're looking for something cross-platform either.. ;-) Ralf ___ 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 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. Anyway, it the Brook author's choice. Regards, - Graeme - ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Indexing files
On 15/12/2012 21:55, Michael Van Canneyt wrote: There is a similar mechanism on windows, but I haven't had time to look at it yet: I wanted to make a unified architecture for this kind of things. I created a truly single source cross-platform system for this. Register your interest (file, directory or everything), and a background thread does the work freeing up your UI. I don't use any OS specific API's, and it is still fast. Regards, - Graeme - ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
