On Thu, 14 Oct 2010 00:47:00 +0200, Jonas Maebe
wrote:
>
>On 09 Oct 2010, at 20:54, Jonas Maebe wrote:
>
>>
>> I sent the request to GMANE only a few minutes before I posted the above to
>> the mailing list, so it's quite likely that they have not yet had the chance
>> to change anything.
>
>I
On 22 Oct 2010, at 21:50, Bernd Kreuss wrote:
> On 22.10.2010 21:23, Jonas Maebe wrote:
>
>> It's only a cosmetic problem, there is no problem with the heap itself. It's
>> a known bug, related to reallocmem:
>> http://bugs.freepascal.org/view.php?id=15805
>
> If I understand this correctly t
In our previous episode, Bernd Kreuss said:
> > It's only a cosmetic problem, there is no problem with the heap itself.
> > It's a known bug, related to reallocmem:
> > http://bugs.freepascal.org/view.php?id=15805
>
> If I understand this correctly then these are only meaningless counters
> that
On 22.10.2010 21:23, Jonas Maebe wrote:
> It's only a cosmetic problem, there is no problem with the heap itself. It's
> a known bug, related to reallocmem:
> http://bugs.freepascal.org/view.php?id=15805
If I understand this correctly then these are only meaningless counters
that come out of sy
On 22 Oct 2010, at 21:20, Bernd Kreuss wrote:
> Is this a known problem and nothing to worry about or am I asking for
> trouble if I ignore this?
It's only a cosmetic problem, there is no problem with the heap itself. It's a
known bug, related to reallocmem: http://bugs.freepascal.org/view.php?
Does anybody know what has become of this:
http://free-pascal-general.1045716.n5.nabble.com/TFPCHeapStatus-miscalculations-in-2-3-1-td2824362.html
I am currently experiencing the same problem. The only thing my Program
does on the heap are ansistring manipulations, concatenating strings to
new str
On Fri, Oct 22, 2010 at 2:44 AM, Martin Schreiber wrote:
> The problem is in TypeStrings, ftLargeInt should return 'bigint' instead
> of 'int'. Fixed in MSEide+MSEgui trunk 4028.
> http://developer.berlios.de/svn/?group_id=11520
Thanks Martin!
> Interresting, MSEgui is used in production since y
http://wiki.lazarus.freepascal.org/EpikTimer
--
Felipe Monteiro de Carvalho
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
On Fri, 22 Oct 2010, Frank Church wrote:
How accurate can a timestamp be calculated in FreePascal?
Is the the Now() function accurate to more than a millisecond?
No. A millisecond is the most.
The datatype (double) may allow more, but it is not taken into account when
comparing or converti
How accurate can a timestamp be calculated in FreePascal?
Is the the Now() function accurate to more than a millisecond?
--
Frank Church
===
http://devblog.brahmancreations.com
___
fpc-pascal maillist - fpc-pascal@lists.freepasca
On Fri, 22 Oct 2010, Jonas Maebe wrote:
On 22 Oct 2010, at 11:21, Michael Van Canneyt wrote:
On Fri, 22 Oct 2010, Martin Schreiber wrote:
Andrew Brunner wrote:
The problem is in TypeStrings, ftLargeInt should return 'bigint' instead
of 'int'. Fixed in MSEide+MSEgui trunk 4028.
http://dev
On 22 Oct 2010, at 11:21, Michael Van Canneyt wrote:
On Fri, 22 Oct 2010, Martin Schreiber wrote:
Andrew Brunner wrote:
The problem is in TypeStrings, ftLargeInt should return 'bigint'
instead
of 'int'. Fixed in MSEide+MSEgui trunk 4028.
http://developer.berlios.de/svn/?group_id=11520
In
On Fri, 22 Oct 2010, Martin Schreiber wrote:
Andrew Brunner wrote:
I've got a problem with the PostgreSQL component. I've got an insert
statement with int64 values. The prepare command goes through but the
server denies the entire packet with the string value of the int64 is
too large for
Andrew Brunner wrote:
> I've got a problem with the PostgreSQL component. I've got an insert
> statement with int64 values. The prepare command goes through but the
> server denies the entire packet with the string value of the int64 is
> too large for integer type error.
>
> The fields were al
14 matches
Mail list logo
