Am Montag, 31. Januar 2011 00:57 schrieb Paul Ishenin:
31.01.2011 0:26, Sven Barth wrote:
Timings without that change:
Run 1:
real1m3.461s
user0m45.957s
sys0m4.590s
Timings with that change:
Run 1:
real1m8.919s
user0m46.597s
sys0m4.166s
But
Am Samstag, 13. Februar 2010 11:15 schrieb Jonas Maebe:
On 13 Feb 2010, at 11:10, ABorka wrote:
My ppc386.exe is v2.5.1 compiled back in September
Building FPC svn trunk has always been and will always be only
supported when starting using the compiler the latest official
release (which is
Am Mittwoch, 27. Januar 2010 09:17 schrieb Marco van de Voort:
In our previous episode, Burkhard Carstens said:
(implemented as TThread descendants if it matters) with no
syncronization/serialization whatsoever. Can I be sure that such
components will not interfere each other implicitely
Am Mittwoch, 27. Januar 2010 02:08 schrieb Nikolai Zhubr:
Hello people,
Is FCL thread-safe?
To be more precise, what I mean is the following. I'm going to create
2 (or more) components so that they are completely unrelated to each
other in _my_ code and use them separately within different
Am Montag, 29. September 2008 09:25 schrieb Michael Schnell:
The encoding can be important for speed:
For example the widestring xml parser is up to 10 times slower than
the ansistring xml parser.
That obviously is the reason why Turbo - Delphi uses UCS-2 (16 bit)
instead of OF UTF-8 or
Am Mittwoch, 6. August 2008 21:37 schrieb Sergei Gorelkin:
Mattias Gaertner wrote:
On Wed, 6 Aug 2008 19:41:27 +0100
Inoussa OUEDRAOGO [EMAIL PROTECTED] wrote:
Hi,
TAVLTree in avl_tree.pp is not thread safe due to the node
allocation and de-allocation done through the global
Am Mittwoch, 6. August 2008 20:41 schrieb Inoussa OUEDRAOGO:
Hi,
TAVLTree in avl_tree.pp is not thread safe due to the node
allocation and de-allocation done through the global
declared NodeMemManager variable. TAVLTreeNodeMemManager
implementation is cleary not thread safe, which btw IMHO
Am Dienstag, 29. Mai 2007 20:51 schrieb Graeme Geldenhuys:
On 5/29/07, Joao Morais [EMAIL PROTECTED] wrote:
Hi,
Attached is a application that demonstrates a bug in FormatFloat.
All tests pass when run under Delphi, but test four fails under
Free Pascal.
IMHO, fpc behaves
Am Dienstag, 13. Februar 2007 16:32 schrieb Michael Van Canneyt:
On Tue, 13 Feb 2007, Michael Schnell wrote:
I was told that in the next not yet released Lazarus version there
will be a platform independent feature that lets you create daemons
(applications without user interface).
I
Am Dienstag, 13. Februar 2007 17:42 schrieb Michael Van Canneyt:
On Tue, 13 Feb 2007, Burkhard Carstens wrote:
Am Dienstag, 13. Februar 2007 16:32 schrieb Michael Van Canneyt:
On Tue, 13 Feb 2007, Michael Schnell wrote:
I was told that in the next not yet released Lazarus version
Am Mittwoch, 24. Januar 2007 09:54 schrieb [EMAIL PROTECTED]:
Sorry... that was for the Indy's mailing list.
Is there a mailing list? I am only aware of the newsgroup.
However if someone of you can help me to install that package i still
need some help.
Sorry again.
Hi, I want to install
Am Mittwoch, 24. Januar 2007 12:09 schrieb [EMAIL PROTECTED]:
Points 1 to 3 went good, i get this error at point 4:
C:\indy\fpcd:\ALVISE\Delphi-Lazarus\IDE\lazarus\fpc\2.1.1\bin\i386-w
in32\make.e xe install
d:/ALVISE/Delphi-Lazarus/IDE/lazarus/fpc/2.1.1/bin/i386-win32/fpcmake
.exe -p -Ti
Am Mittwoch, 24. Januar 2007 13:02 schrieb [EMAIL PROTECTED]:
Burkhard Carstens ha scritto:
Am Mittwoch, 24. Januar 2007 12:09 schrieb
[EMAIL PROTECTED]:
Points 1 to 3 went good, i get this error at point 4:
C:\indy\fpcd:\ALVISE\Delphi-Lazarus\IDE\lazarus\fpc\2.1.1\bin\i38
6-w in32\make.e
Am Mittwoch, 27. September 2006 22:36 schrieb Christian Iversen:
Hi all.
I was hoping there could be a discussion of a certain feature in FPC,
which doesn't work very well for us. Ultimately, I would like to see
it gone completely. It's a very small extra-strong syntax check,
appearantly
Am Freitag, 8. September 2006 21:44 schrieb Robert Reimiller:
[..]
I'm using objfpc mode. Changing addr(libthread) into @libthread
solved the problem.
I should have thought of that since I had the same problem with
getting the address of a callback procedure. It now all compiles, now
for the
Am Mittwoch, 6. September 2006 11:05 schrieb Michael Van Canneyt:
On Wed, 6 Sep 2006, Ale Katona wrote:
The problem here is that if you introduce a changing type to Tag,
you're going to break streaming of the components between various
platforms. However I think simplest would be to simply
* Happens at least on linux-32 with make all as well as make all
OS_TARGET=win32
* fpcfan reported similar error on i386-netware
see http://paste.lisp.org/display/24017 for a buildlog
regards
Burkhard
___
fpc-devel maillist -
Am Samstag, 12. August 2006 09:53 schrieb Burkhard Carstens:
* Happens at least on linux-32 with make all as well as make all
OS_TARGET=win32
* fpcfan reported similar error on i386-netware
see http://paste.lisp.org/display/24017 for a buildlog
.. forgot to mention: r4409 works fine, just
Am Sonntag, 16. Juli 2006 18:38 schrieb Florian Klaempfl:
Florian Klaempfl wrote:
Burkhard Carstens wrote:
Tha attached patch changes the statistic functions (sum, mean,
stddev etc.) to expect array of double instead of array of
float. For most of the functions, I left the result values
Am Sonntag, 16. Juli 2006 20:47 schrieb Marco van de Voort:
Florian Klaempfl wrote:
This is probably ancient stuff so for new stuff we should care
about it
:) I'll try to modify your patch.
After a second thought I applied it unmodified because
architectures not supporting
Tha attached patch changes the statistic functions (sum, mean, stddev
etc.) to expect array of double instead of array of float.
For most of the functions, I left the result values of type float as in
D7, they are also type extended. Only for minvalue and maxvalue, I
changed the result also to
Am Donnerstag, 6. Juli 2006 12:15 schrieb Alejandro Lucas Baldres:
How to apply the patch? Thank you
It is allready applied to the svn trunk.
If you need to do it by hand, I think patch -p0 fixalign.patch in
fpc source dir should do it.
regards
Burkhard
fpc-2.1.1 r4075
linux-i386
If I understand the purpose of function align
(rtl/inc/{systemh.inc,generic.inc}) correctly, it gives wrong results
when used with pointers $800.
Align uses ptrint. Using ptrUint instead works.
I tried using it to align a array to 4k bounds, like this:
.. there are similar problems with other align functions:
function aligntoptr in
rtl/inc/dynarr.inc
rtl/inc/variants.pp
aligntoptr($7001) - 7004 //correct
aligntoptr($8001) - 8008 //wrong
These are only relevant to platforms where
$FPC_REQUIRES_PROPER_ALIGNMENT
function
System: Linux i386
Affected revisions: svn-trunk 2949 - 2952 (current)
$ make distclean all
[..]
dsparams.inc(433,5) Error: Asm: 64 Bit operands not supported
dsparams.inc(892,3) Fatal: There were 1 errors compiling module,
stopping
Fatal: Compilation aborted
make[4]: Leaving directory
System: Linux i386
Affected revisions: svn-trunk 2949 - 2952 (current)
Fixed.
Thanks!
Burkhard
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
26 matches
Mail list logo
