Jonas Maebe wrote:
On 09 Apr 2007, at 22:38, Colin Western wrote:
Having said that, for numerical programming if double is wanted, the
evaluation as double in the absence of specific precision information
is actually desirable, and avoids some hard to find errors. Values
like Sqrt(2
Jonas Maebe wrote:
On 06 Apr 2007, at 21:36, Colin Western wrote:
Can I ask what determines the precision of floating point calculations
are done in? It seems that fpc treats (for example, with J declared as
integer)
1/sqrt(J+1.0) as single
but
1/sqrt(J+1) as double
In 2.1.2 and 2.2
Can I ask what determines the precision of floating point calculations
are done in? It seems that fpc treats (for example, with J declared as
integer)
1/sqrt(J+1.0) as single
but
1/sqrt(J+1) as double
which seems counter-intuitive. In FORTRAN I can force double precision
evaluation with
Is there a good reason why RunError does not raise an exception in the
same way that HandleError does (if SysUtils is installed)? RunError is a
particularly bad routine to call from a thread as it starts finalizing
variables that are most likely still in use by other threads. An
exception
Vincent Snijders wrote:
Hi,
I saw in the log message of revision
http://www.freepascal.org/cgi-bin/viewcvs.cgi?diff_format=lrev=3784sortby=dateview=rev
that the xml units now use native line ending.
Previously I noticed they were using #10 for line-ending and was told
this was conform the
The attached patch fixes two crashes I had with TFPWriterXPM:
1. If there was more than 60 or so colours in the palette
2. If the TFPCustomImage did not have a palette.
Colin
diff -uNr trunk/fpcsrc/fcl/image/fpwritexpm.pp trunk.w/fpcsrc/fcl/image/fpwritexpm.pp
---
Peter Vreman wrote:
I thought the following message on the valgrind users list might be of
interest - it is in response to a message I posted. (The reply came
months after the original, so I didn't notice it immediately). I do not
know how to respond to the question at the end. The first patch
I thought the following message on the valgrind users list might be of
interest - it is in response to a message I posted. (The reply came
months after the original, so I didn't notice it immediately). I do not
know how to respond to the question at the end. The first patch at least
seems to
Gerhard Scholz wrote:
I've tried to submit this as a bug report, but after pressing on Submit bug
nothing happens on http://www.freepascal.org/bugs/add.php3
Inc ( v, i ) and Dec ( v, i ) produce rangecheck or overflow check with {$r+,q+}
Without checks the program runs corrctly.
snip
Thanks for fixing bug 4118. I had to apply the attached patch to get the
current svn to compile under linux
Colin
diff -uNr trunk/fpcsrc/rtl/inc/wstrings.inc trunk.w/fpcsrc/rtl/inc/wstrings.inc
--- trunk/fpcsrc/rtl/inc/wstrings.inc 2005-06-26 09:39:22.0 +0100
+++
The attached fixes a 32 bit overflow problem when writing PNG files
using 16 bits per colour
Colin
diff -uNr trunk/fpcsrc/fcl/image/fpwritepng.pp trunk.w/fpcsrc/fcl/image/fpwritepng.pp
--- trunk/fpcsrc/fcl/image/fpwritepng.pp 2005-06-11 09:58:32.0 +0100
+++
Joost van der Sluis wrote:
On Mon, 2005-06-20 at 22:12 +0100, Colin Western wrote:
I found two minor problems (so far) on Fedora Core 4 (current svn):
1. The Copyright: tag must be License: in the fpc.spec file.
(Apparently Copyright: has been deprecated for a while).
2. The samplecfg
The attach fixes two problems I found reading pnm files:
- RGB files were not being read correctly
- byte values of 255 were overflowing.
I have adjusted the colour scaling to be compatible with what happens
for .BMP files. I have not been able to do much testing, as I am short
of files to
Gerhard Scholz wrote:
snip
It seems that the compiler now sees a ord(c) to be a BYTE, and BYTE - BYTE
shall give a BYTE, and -1 is not in the range allowed for a BYTE.
Thanks for taking a look at this. I am reasonably sure that this
beheviour is wrong, (otherwise you could never take the
Can I ask somebody to have another look at this bug - it was flagged
unreproducable on the web system, but I still get it from the current
svn as shown below.
(Note that the orginal report was on ppc but I have the same fault on i386)
Colin
$ fpc ord.pas
Free Pascal Compiler version 2.1.1
Florian Klaempfl wrote:
C Western wrote:
I tried out valgrind on lazaraus and one of my own lcl programs, and
was able to get it working by after applying some small patches to
valgrind (which I have sent to the valgrind mailing lists). valgrind
found some uninitialised memory reads, which the
The attached patch provides some small fixes so that make rpm works -
it was not working for me under Fedora, and I think the fixes are not
restricted to the distribution I am using.
1. Fix bug number 2773
2. Allow make rpm to work as non root user
3. Fix to archive names generated by owar.pas
The sense of the result of FileIsReadOnly seems to be inverted - see
attched patch
Colin
diff -uNr fpc/rtl/unix/sysutils.pp fpc.w/rtl/unix/sysutils.pp
--- fpc/rtl/unix/sysutils.pp 2004-04-20 20:15:42.0 +0100
+++ fpc.w/rtl/unix/sysutils.pp 2004-04-24 19:07:08.0 +0100
@@ -321,7
I think some calls to Changing/Changed are missing from TStrings /
TStringList - see attached patch
Colin
diff -uNr fpc/fcl/classes/stringl.inc fpc.w/fcl/classes/stringl.inc
--- fpc/fcl/classes/stringl.inc 2003-10-06 21:33:58.0 +0100
+++ fpc.w/fcl/classes/stringl.inc 2004-04-14
Reading the bitmap docs, and a test of one bitmap makes me think the
following patch is required:
diff -uNr fpc/fcl/image/fpreadbmp.pp fpc.w/fcl/image/fpreadbmp.pp
--- fpc/fcl/image/fpreadbmp.pp 2004-02-20 23:12:57.0 +
+++ fpc.w/fcl/image/fpreadbmp.pp2004-02-22
[EMAIL PROTECTED] wrote:
I am not the maintainer, but I have been tinkering with it. Attached is
a patch containing my efforts so far
Thank you. I have reviewed and applied the patches. Feel free to send more
patches and/or suggestions.
As for the BMP reader: it is scheduled for rewriting, I
I attach a patch for the rtl reader for dfm/lfm type files, in the hope
that it might be useful. It fixes some problems with reading inherited
forms, and implements reading utf8 strings (though it just discards
everything other than the bottom eight bits). Both helped in reading
some Delphi
22 matches
Mail list logo
