[fpc-pascal] FPC fails to build rev 31874
FPC revision 31874 is failing to build with the following error: pexpr.pas(3990,48) Error: Incompatible type for arg no. 1: Got "tnode", expected "tsym" Last Changed Author: nickysn Last Changed Date: 2015-09-27 20:17:53 -0400 (Sun, 27 Sep 2015) ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPC fails to build rev 31874
2015-09-28 11:08 GMT+02:00 Anthony Walter : > FPC revision 31874 is failing to build with the following error: > > pexpr.pas(3990,48) Error: Incompatible type for arg no. 1: Got "tnode", > expected "tsym" > > Last Changed Author: nickysn > Last Changed Date: 2015-09-27 20:17:53 -0400 (Sun, 27 Sep 2015) > > See also: http://bugs.freepascal.org/view.php?id=28738 Vincent ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPC fails to build rev 31874
Thanks ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPC fails to build rev 31874
Am 28.09.2015 11:21 schrieb "Anthony Walter" : > > Thanks Please test again with 31875. Sorry for the inconvenience... Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] TDBF (dBase) vs TurboPower FlashFiler
Hello Michael, On 2015-09-26 at 14:07, Michael Van Canneyt wrote: > I seem to remember that FlashFiler supported cross-table queries. > TDBF does not. Thanks - that is quite an important point and concern for me. Regards, - Graeme - fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ My public PGP key: http://tinyurl.com/graeme-pgp ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPC fails to build rev 31874
Fixed. Thanks Sven. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] PostgreSQL notifications broken
Michael Van Canneyt wrote: On Fri, 11 Sep 2015, Mark Morgan Lloyd wrote: PostgreSQL has a useful feature where application programs can send notifications to each other, this tends to be much "cheaper" than periodically polling a table for changes. I've had this working on various CPUs and OSes in a number of programs since at least 2.2.4, but it appears to have been broken at some point between 2.6.0 and 2.6.4 with problems persisting through to 3.0.0-rc1 and trunk. The specific fragment of code that's failing looks like this: result := badPoll; if PQStatus(DbTF.PQConnection1.Handle) <> CONNECTION_OK then exit; pqConsumeResult := PQconsumeInput(DbTF.PQConnection1.Handle); if PQStatus(DbTF.PQConnection1.Handle) <> CONNECTION_OK then exit; If DbTF.PQConnection1 is of type TPQConnection then I think this is your problem. The low-level handle has been moved to the transaction. DbTF.PQConnection1.Handle is then a stub, of no value. Any chance of a hint where to find the new long-life handle, i.e. the one that corresponds to the connect action with username, password etc. properties? The change was between 2.6.2 and 2.6.4, I've been looking at sqldb.pp and related files but so far haven't tracked it down. Discussing this sort of thing elsewhere, at least PostgreSQL, Firebird/Interbase and Oracle provide comparable notification/event features with varying degrees of functionality. If encapsulating this sort of thing in libraries or components, it would be highly desirable to be able to rely on the availability of a persistent handle. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] PostgreSQL notifications broken
On Mon, 28 Sep 2015, Mark Morgan Lloyd wrote:
Michael Van Canneyt wrote:
On Fri, 11 Sep 2015, Mark Morgan Lloyd wrote:
PostgreSQL has a useful feature where application programs can send
notifications to each other, this tends to be much "cheaper" than
periodically polling a table for changes.
I've had this working on various CPUs and OSes in a number of programs
since at least 2.2.4, but it appears to have been broken at some point
between 2.6.0 and 2.6.4 with problems persisting through to 3.0.0-rc1 and
trunk. The specific fragment of code that's failing looks like this:
result := badPoll;
if PQStatus(DbTF.PQConnection1.Handle) <> CONNECTION_OK then
exit;
pqConsumeResult := PQconsumeInput(DbTF.PQConnection1.Handle);
if PQStatus(DbTF.PQConnection1.Handle) <> CONNECTION_OK then
exit;
If DbTF.PQConnection1 is of type TPQConnection then I think this is your
problem. The low-level handle has been moved to the transaction.
DbTF.PQConnection1.Handle is then a stub, of no value.
Any chance of a hint where to find the new long-life handle, i.e. the one
that corresponds to the connect action with username, password etc.
properties?
pqconnection, start of the unit:
{ TPQTrans }
TPQTrans = Class(TSQLHandle)
protected
PGConn : PPGConn;
FList : TThreadList;
Procedure RegisterCursor(Cursor : TPQCursor);
Procedure UnRegisterCursor(Cursor : TPQCursor);
Public
Constructor Create;
Destructor Destroy; override;
end;
PGConn is what you're looking for.
TPQTrans is referenced in :
TPQCursor = Class(TSQLCursor)
protected
Statement: string;
StmtName : string;
tr : TPQTrans;
The change was between 2.6.2 and 2.6.4, I've been looking at sqldb.pp and
related files but so far haven't tracked it down.
Discussing this sort of thing elsewhere, at least PostgreSQL,
Firebird/Interbase and Oracle provide comparable notification/event features
with varying degrees of functionality. If encapsulating this sort of thing in
libraries or components, it would be highly desirable to be able to rely on
the availability of a persistent handle.
The above should be sufficient ?
But the mechanisms are different for each DB, so a unified mechanism is not
something we are considering, to my knowledge.
If you look at the pqeventmonitor unit, you will see that it bypasses
completely the usual TSQLConnection mechanisms.
Michael.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] PostgreSQL notifications broken
Michael Van Canneyt wrote:
On Mon, 28 Sep 2015, Mark Morgan Lloyd wrote:
Michael Van Canneyt wrote:
On Fri, 11 Sep 2015, Mark Morgan Lloyd wrote:
PostgreSQL has a useful feature where application programs can send
notifications to each other, this tends to be much "cheaper" than
periodically polling a table for changes.
I've had this working on various CPUs and OSes in a number of
programs since at least 2.2.4, but it appears to have been broken at
some point between 2.6.0 and 2.6.4 with problems persisting through
to 3.0.0-rc1 and trunk. The specific fragment of code that's failing
looks like this:
result := badPoll;
if PQStatus(DbTF.PQConnection1.Handle) <> CONNECTION_OK then
exit;
pqConsumeResult := PQconsumeInput(DbTF.PQConnection1.Handle);
if PQStatus(DbTF.PQConnection1.Handle) <> CONNECTION_OK then
exit;
If DbTF.PQConnection1 is of type TPQConnection then I think this is
your problem. The low-level handle has been moved to the transaction.
DbTF.PQConnection1.Handle is then a stub, of no value.
Any chance of a hint where to find the new long-life handle, i.e. the
one that corresponds to the connect action with username, password
etc. properties?
pqconnection, start of the unit:
{ TPQTrans }
TPQTrans = Class(TSQLHandle)
protected
PGConn : PPGConn;
FList : TThreadList;
Procedure RegisterCursor(Cursor : TPQCursor);
Procedure UnRegisterCursor(Cursor : TPQCursor);
Public
Constructor Create;
Destructor Destroy; override;
end;
PGConn is what you're looking for.
TPQTrans is referenced in :
TPQCursor = Class(TSQLCursor)
protected
Statement: string;
StmtName : string;
tr : TPQTrans;
Thanks, I'll take another look but one of the handles I'm tracking is
that PGConn field.
I can see handles changing state in debug output from both
lazarus-1.0.0+2.6.0 and lazarus-1.0.14+2.6.4 (intermediate versions e.g.
lazarus-1.0.8+2.6.2 are more of a problem), and can see them behaving
differently. Knowing that there isn't a third one that I've not yet
located is a big help.
The change was between 2.6.2 and 2.6.4, I've been looking at sqldb.pp
and related files but so far haven't tracked it down.
Discussing this sort of thing elsewhere, at least PostgreSQL,
Firebird/Interbase and Oracle provide comparable notification/event
features with varying degrees of functionality. If encapsulating this
sort of thing in libraries or components, it would be highly desirable
to be able to rely on the availability of a persistent handle.
The above should be sufficient ?
But the mechanisms are different for each DB, so a unified mechanism is
not something we are considering, to my knowledge.
If you look at the pqeventmonitor unit, you will see that it bypasses
completely the usual TSQLConnection mechanisms.
--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk
[Opinions above are the author's, not those of his employers or colleagues]
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] howto find alternatives for deprecated fucntions?
What can I use instead of Sock2Text? That's also deprecated. Am 16.09.2015 um 16:50 schrieb Klaus Hartnegg: www.freepascal.org/docs-html/rtl/sockets/accept.html says that accept is deprecated. Whould I switch to fpaccept eventhough that can do a lot less? I hope that Sock2Text works there as well. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] howto find alternatives for deprecated fucntions?
Klaus Hartnegg wrote on Mon, 28 Sep 2015: What can I use instead of Sock2Text? That's also deprecated. That is part of the "X wanted to remove that functionality altogether and deprecating it was a first step, and Y wanted to keep it". Eventually, it will probably be moved to a separate unit. There is no alternative for that function. Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] Screwed FPC installation in Xubuntu
I was able to get my Xubuntu 15.10 into a state where FPC doesn't work even if I remove and install again from repo. I tried installing FPC 3RC1 but then removed all traces of it. At one point there were links to /etc/alternative created by the Ubuntu package system. After removing everything and then installing FPC 3 using the sh script, there is no fpc.cfg generated. Why not? Strangely I have earlier managed to install FPC 3RC1 without problems in other systems. This is embarrassing. I was planning to use Xubuntu for a while now. Juha ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
