On Wednesday 05 November 2014 19:19:41 Chris Dryburgh wrote:
[...]> run together. It is also read-only transaction idiot proof which is a
> good thing. Michael's approach of allowing for closing a transaction
> without closing a still in use dataset looks like a better approach. It
> will still cau
Vsevolod Alekseyev schrieb:
Hi all,
in the FPC reference at
http://www.freepascal.org/docs-html/ref/refse68.html#x127-13700012.1 ,
the formal grammar spec only goes down as far as factor. Can I please
see the grammar for variable reference? A variable reference can be an
arbitrarily complex
Hi all,
in the FPC reference at
http://www.freepascal.org/docs-html/ref/refse68.html#x127-13700012.1 ,
the formal grammar spec only goes down as far as factor. Can I please
see the grammar for variable reference? A variable reference can be an
arbitrarily complex thing; for example,
MyStruct
On Wed, 5 Nov 2014, Jonas Maebe wrote:
On 05 Nov 2014, at 16:34, Michael Van Canneyt wrote:
As far as I know, the layout of this particular kind of RTTI can be deduced
from the TypInfo unit of Delphi.
At least XE seems to have the info present.
This should be done using a clean room appr
On Wed, 5 Nov 2014, Chris Dryburgh wrote:
of a database server which implements connection pools etc.
Another issue is that once a connection has been established to a named
server, there's a single point of failure if it tries to reopen it but
finds that the nameserver is unavailable. A fa
Am 05.11.2014 21:55 schrieb :
>
> Not bad. I confirm that both Lazarus 1.3 and variables of refcounted type
declared in another unit work now.
Good to know :)
> I wanted to assemble some prototype application with refcounted objects
to see how would such feature behave in a more or less complex p
Not bad. I confirm that both Lazarus 1.3 and variables of refcounted type
declared in another unit work now.
I wanted to assemble some prototype application with refcounted objects to see
how would such feature behave in a more or less complex program; but in spite
of lack of free time I am no
On 05/11/14 05:03 AM, Mark Morgan Lloyd wrote:
Michael Van Canneyt wrote:
On Tue, 4 Nov 2014, Chris Dryburgh wrote:
Hi
In PostgreSQL it is considered poor practice to have long running
idle transactions.
https://encrypted.google.com/#q=postgresql+idle+in+transaction
This is a known proble
On 05/11/14 03:04 AM, Martin Schreiber wrote:
On Tuesday 04 November 2014 19:33:22 Chris Dryburgh wrote:
The end result should be that server transactions only open when needed.
Users would likely commit write transactions quickly to save data to the
database. Read-only transactions might be lef
On 05 Nov 2014, at 16:34, Michael Van Canneyt wrote:
As far as I know, the layout of this particular kind of RTTI can be
deduced from the TypInfo unit of Delphi.
At least XE seems to have the info present.
This should be done using a clean room approach though: one person can
read the cod
On Wed, 5 Nov 2014, Steve Hildebrandt wrote:
Am 05.11.2014 um 13:02 schrieb Michael Van Canneyt:
On Wed, 5 Nov 2014, Jonas Maebe wrote:
Some of the other changes would however need a note on
http://wiki.freepascal.org/User_Changes_Trunk , since they may require changes
t
Am 05.11.2014 um 13:02 schrieb Michael Van Canneyt:
>
> On Wed, 5 Nov 2014, Jonas Maebe wrote:
>
>>
>> Some of the other changes would however need a note on
>> http://wiki.freepascal.org/User_Changes_Trunk , since they may
>> require changes to user code (given that a number of tests also need
>>
On Wed, 5 Nov 2014, Jonas Maebe wrote:
On 05 Nov 2014, at 10:21, Michael Van Canneyt wrote:
For 26773:
this will also need fixes in the compiler, since you propose a change in a
compilerproc.
However, this should be easily doable.
If it's just a change from "var" to "const", nothing nee
Michael Van Canneyt wrote:
On Tue, 4 Nov 2014, Chris Dryburgh wrote:
Hi
In PostgreSQL it is considered poor practice to have long running idle
transactions.
https://encrypted.google.com/#q=postgresql+idle+in+transaction
This is a known problem, not only for postgres.
The problem is the op
On 05 Nov 2014, at 10:21, Michael Van Canneyt wrote:
For 26773:
this will also need fixes in the compiler, since you propose a
change in a compilerproc.
However, this should be easily doable.
If it's just a change from "var" to "const", nothing needs to be
changed in the compiler. The
On Tue, 4 Nov 2014, Alf wrote:
As a (very) long time Pascal programmer (TP/ FPC / Delphi), I have helped the
developer of mORMot (http://synopse.info/fossil/wiki?name=SQLite3+Framework) to
port his framework
to FPC. With success. Many Linux (ARM) servers now run mORMot thanks to FPC.
There
On Tuesday 04 November 2014 19:33:22 Chris Dryburgh wrote:
>
> The end result should be that server transactions only open when needed.
> Users would likely commit write transactions quickly to save data to the
> database. Read-only transactions might be left in a open state but can
> be closed by
On Tue, 4 Nov 2014, Chris Dryburgh wrote:
Hi
In PostgreSQL it is considered poor practice to have long running idle
transactions.
https://encrypted.google.com/#q=postgresql+idle+in+transaction
This is a known problem, not only for postgres.
The problem is the open transaction for an open
18 matches
Mail list logo
