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) are
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 sqr
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 makes
Michael Van Canneyt wrote:
On Sun, 26 Nov 2006, C Western wrote:
Does the syncobjs unit in the FCL need to be machine dependent any more? The
functionality seems to be in the thread manager for all the platforms that
have threads, and I had some problems using the unit. (TRTLCriticalSection is
Amir Aavani wrote:
InitCriticalSection (cs);
while true do
begin
EnterCriticalsection (cs);
WriteLn ('Here!');
end;
LeaveCriticalsection (cs);
Each Enter.. must be matched by a Leave..., and you don't need the loop.
The standard way of doing this is:
EnterCriticalsection (cs);
Vincent Snijders wrote:
Hi,
I saw in the log message of revision
http://www.freepascal.org/cgi-bin/viewcvs.cgi?diff_format=l&rev=3784&sortby=date&view=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 t
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
--- trunk/fpcsrc/fcl/image/fpwritex
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 a
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 ha
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.
This
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
+++ trunk.w/fpcsrc/rtl/inc/ws
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
+++ trunk.w/fpcsrc/fcl/image/fpwrit
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 de
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 script fails, probably because the upgrade to gcc 4
has changed the output of gcc -v
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 test,
Peter Vreman wrote:
Gerhard Scholz wrote:
The check for overflow is obviously implemented different in 2.0.0 and
2.1.1
I'm not sure, at least
.L9:
movw %dx,-12(%ebp)
.Ll3:
suggests that the target is not an integer, but instead is a (possibly
unsigned) word type.
Gerhard Scholz wrote:
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 diffe
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 [2005
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 a
[EMAIL PROTECTED] wrote:
On Sat, 22 Jan 2005, C Western wrote:
With the attached patch to the FCL applied, I have been able to read
inherited forms with the LCL
Can you also design them in the Lazarus IDE ?
Not at the moment. I also have some patches to LCL to allow an
application usin
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.pa
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 +321,
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 22:31:35.00
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 00:24:01.0
[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 wa
Marc Weustink wrote:
Hi,
Is there a maintainer for fpImage ? And what is the development status
of fp(read|write)bmp ? Is anyone working on adding other encodings
than 32 bit ?
If not, than I'll have a try to add the missing encodings.
I am not the maintainer, but I have been tinkering with it.
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 gen
I think there is a problem with testing the return values from linux
syscalls; at least under i386 negative values can be OK. Looking at the
glibc source I find:
DO_CALL (syscall_name, args);
cmpl $-4095, %eax;
jae SYSCALL_ERROR_LABEL;
rather than a simple test on the sign that
I have spotted a problem with TFPReaderXPM, in that it uses a case
insensitive compare on the colour symbols. I think it needs the following:
diff -uNr fpc/fcl/image/fpreadxpm.pp fpc.w/fcl/image/fpreadxpm.pp
--- fpc/fcl/image/fpreadxpm.pp 2003-08-17 19:33:04.0 +0100
+++ fpc.w/fcl/image/f
30 matches
Mail list logo
