Re: [fpc-devel] Status report for class helpers
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 previously you gave 2 minutes values. AFAIK, the real time is pretty meaningless. It just says how much time passed between prg start and prg end. The user time is the interesting one. It says how much processor time the prg used actually doing something instead of waiting to be sheduled by the OS. That's why a multithreaded app on a multi-core can have higher user time than real time. regards Burkhard ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] fpc 14894 svn does not compile
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 2.4.0 at this time). Is there a place when I can download the newer binary files/utils needed for the compile if that is the problem? You can download the latest release from the website. It would be nice to have a minimum binary package(*) for those who usually compile svn. (*) for linux, this would contain only ppc386-240, which is only 770K as tar.bz2 (or 821K as tar.gz) instead of 26MB/34MB of rpm/ one-big-file.tar. regards Burkhard ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FCL Thread-safety
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 (somewhere deep inside the FCL)? No, you can't be sure. E.g. the fcl-xml stuff in latest released fpc-2.4.0 is *not* thread-safe, because it uses avl-tree which is not thread-safe. See http://mantis.freepascal.org/view.php?id=12984 and note: This bug is marked as fixed in 2.4.0 which is (partly) wrong. Avltree is fixed in 2.4.0 (you can set an own manager), and that is what the report is about (see title: Patch : thread safe/non-safe avl_tree implementation ) XML is not fixed. Right, that's why I wrote (partly) wrong .. relation to xml was the main point in that bug report and your final note Solved now DOM no longer depends on avltree. together with fixed in 2.4.0 might give the impression, XML is fixed in 2.4.0 .. regards Burkhard ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FCL Thread-safety
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 threads (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 (somewhere deep inside the FCL)? No, you can't be sure. E.g. the fcl-xml stuff in latest released fpc-2.4.0 is *not* thread-safe, because it uses avl-tree which is not thread-safe. See http://mantis.freepascal.org/view.php?id=12984 and note: This bug is marked as fixed in 2.4.0 which is (partly) wrong. The problem with xml stuff depending on avl-tree is fixed only in trunk and in fixes_2_4 (i.e. 2.4.1). So using e.g. xmlcfg is thread-safe only, if fpc 2.4.0 is used. About avl-tree: IIRC it *can* be used in a thread-safe manner, but by default, it is not thread-safe. So any component using avl-tree might not be thread-safe. There might be much more stuff like this, so I recommend to verify every components you intend to use. And just in case someone knows, will zeoslib components be thread-safe in the same sense? From a brief look, zeoslib doesn't use global variables too much, so I suppose zeoslib thread-safety mostly depends on the FCL thread-safety. (Except that zeoslib's internal library loader seems definitely not thread-safe, but this is no problem because normally it should only be used once at the very beginning) No idea, never used zeos. regards Burkhard ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Is calling the Windows Unicode APIs really faster than the ANSI API's?
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 UTF-16 for WideStrings (and WideChar is a 16 bit (UCS-2) value). You didn't read http://www.jacobthurman.com/?p=30 , did you? regards Burkhard ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] TAVLTree(avl_tree.pp) thread safety, fcl-xml(DOM) is also concerned.
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 declared NodeMemManager variable. TAVLTreeNodeMemManager implementation is cleary not thread safe, which btw IMHO is a good thing ( for performance reason). Proposition : (a) TAVLTree should allow, at construct time, to specify a Node memory manager which will be kept and used. If not specified the global one will be used. (b) NodeMemManager should be declared as ThreadVar. This changes does not break the API while making the implementation thread safe. By the way note that the XML DOM's implementation ( TDOMNode_WithChildren ) uses TAVLTree, so every code that uses the fcl-xml package mainly the DOM unit, is not thread safe. If this proposition is accepted it will be nice to have it introduced in the soon to be release fpc 2.2.2, in the case that is still possible, mainly for server programming. Attached is a patch that demonstrate the above proposition. Providing a local node mem manager does not repair xml dom. Maybe move NodeMemManager to the interface, so that a user can replace it with a threadsafe one? Since this topic is touched, I would like to vote for removing avl_tree dependency from the DOM altogether. The reason is that the avl tree of child nodes is useless for any real-world XML data because it does not handle duplicate names. The tree is useful only for the one particular case of XML configs where each node name is unique. OTOH, it causes considerable performance penalties (each insert results in two searches, first one for checking the existence, second one for insert itself; each search is a number of calls to Node.GetNodeName, which, in case of Windows, is a Widestring copy, etc.) Therefore I'd suggest to remove the avltree from DOM. This would be great to have in 2.2.2. In order to keep configs at the reasonable speed, it is possible to implement indexing within TXMLConfig class itself, preferably hashmap-based. This would be a performance tweak which (from my POV) does not need to be in 2.2.2, although it would be nice. Alternatively, it is possible to use Registry-like access (OpenKey/CloseKey methods) that I had already implemented in newer xmlconf.pp unit. The advantage is that the searches are done starting from the 'opened key', not from the root, so linear search isn't too slow. If I understand correctly, this would change the usage of xmlconfig which would require changes to any existing code using it? If so, it's probably not an option for 2.2.2, maybe even not for 2.2.4 .. regards Burkhard ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] TAVLTree(avl_tree.pp) thread safety, fcl-xml(DOM) is also concerned.
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 is a good thing ( for performance reason). Proposition : (a) TAVLTree should allow, at construct time, to specify a Node memory manager which will be kept and used. If not specified the global one will be used. (b) NodeMemManager should be declared as ThreadVar. This changes does not break the API while making the implementation thread safe. By the way note that the XML DOM's implementation ( TDOMNode_WithChildren ) uses TAVLTree, so every code that uses the fcl-xml package mainly the DOM unit, is not thread safe. If this proposition is accepted it will be nice to have it introduced in the soon to be release fpc 2.2.2, in the case that is still possible, mainly for server programming. Attached is a patch that demonstrate the above proposition. What about this: * let TAVLTree access the node manager using a local reference (TAVLTree.FNodeMemManager) * in TAVLTree.create: if IsMultiThread then FNodeMemManager:=TAVLTreeNodeMemManager.create else FNodeMemManager:=NodeMemManager; * in TAVLTree.destroy: if IsMultiThread then FNodeMemManager.free; This way, nothing would change for single threaded apps but it would be fully threadsafe for multithreaded (AFAIKS). This is probably not a perfect solution, but the least intrusive one .. regards Burkhard ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FormatFloat bug
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 correctly. 0.005 is closer than 0 instead 0.01. If you try 0.0050001, you will have 0.01, also correct. Normally you would round 5 or higher up so taking 0.005 to two decimal places would give you 0.01 which is what Delphi does! This is mathematically correct. It's got nothing to do with whether it is closer to zero or to one. Try 0.015, that should round to 0.02. IIRC, it's round-to-even, see http://en.wikipedia.org/wiki/Rounding. regards Burkhard ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] daemon units in Lazarus (to Michael van Canneyt ?)
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 need to do something like this. Is there any documentation on how this works ? I'll send you some in private. Is there a reason why you prefer sending such things in private? I'd be also interested in this documentation as well as in the article about how to use fpcunit (for beginners) (mentioned in another thread). Kind reagrds Burkhard ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] daemon units in Lazarus (to Michael van Canneyt ?)
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 there will be a platform independent feature that lets you create daemons (applications without user interface). I need to do something like this. Is there any documentation on how this works ? I'll send you some in private. Is there a reason why you prefer sending such things in private? I'd be also interested in this documentation as well as in the article about how to use fpcunit (for beginners) (mentioned in another thread). Yes, there is. This is text which is published in a journal and is under copyright. I am not allowed to send this to just anyone. A couple of people is OK, but I cannot make it publicly available... Sorry for asking .. just remember, you already answered this question at least once .. ;-) However, of course I'd prefer to get those docs in private over not having them at all :-) So if it fits into the couple of people quantum, I'd really apprecite, if you could send them to me, too (especially the daemon ones). Regards Burkhard ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] The Lazarus Indy Package
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 and try Indy cause i heard of some windows mobile cross compilation success with Lazarus. But, the lazarus package is not able to install in the ide, and one of the developers that some days ago came on Lazarus IRC channel said i have to compile it as stand alone package and after that put it into Lazarus. Not able to install is somewhat meaningless. Please describe what you do, and what error you get. Please be aware: indy comes in one archive, containing two parts: 1. the fpc subfolder - this contains the indy-core (aka. indy-rtl ? ): all the classes and stuff you need to compile indy-programs with fpc. This one does not need lazarus. This one has to be compiled and installed first. 2. the lazarus subfolder - this contains the design-time components: all the things you need to create lazarus gui-apps using the lazarus component palette and form designer. AFAIK, these are not needed for compiling your projects (gui or console). Only for the RAD design process. so here are the steps to do: (this is on linux, but should be similar on win) 1. download the package from www.indyproject.org/Sockets/fpc/index.html 2. unpack it and change into indy/fpc/ 3. run make all 4. run make install 5. run make sourceinstall INSTALL_FPCSUBDIR=fpc/packages/extra Now you can compile indy-progs with fpc. 6. rebuild lazarus (not sure, if this is necessary, I do it because I allways recompile everything ;-) ) 7. start lazarus 8. open the indy/lazarus/indylaz.lpk 9. compile and install it (this rebuilds the ide again) 10. now you should find a lot of indy components on your component palette. 11. have fun regards Burkhard ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] The Lazarus Indy Package
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 386-win32 Makefile.fpc Processing Makefile.fpc Error: Target win32, package rtl not found d:\ALVISE\Delphi-Lazarus\IDE\lazarus\fpc\2.1.1\bin\i386-win32\make.ex e: *** [fpc _install] Error 1 How do I set rtl (and other) paths? try setting the envvar FPCDIR to point to fpc sources. In linux, I do a export FPCDIR=/usr/local/share/src/fpc-2.1.1/fpc/ Hree this is only need when building a indy-rpm .. p.s. yes there's a mailing list too where ? regards Burkhard ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] The Lazarus Indy Package
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 xe install d:/ALVISE/Delphi-Lazarus/IDE/lazarus/fpc/2.1.1/bin/i386-win32/fpcm ake .exe -p -Ti 386-win32 Makefile.fpc Processing Makefile.fpc Error: Target win32, package rtl not found d:\ALVISE\Delphi-Lazarus\IDE\lazarus\fpc\2.1.1\bin\i386-win32\make .ex e: *** [fpc _install] Error 1 How do I set rtl (and other) paths? try setting the envvar FPCDIR to point to fpc sources. In linux, I do a export FPCDIR=/usr/local/share/src/fpc-2.1.1/fpc/ Hree this is only need when building a indy-rpm .. I tryed to set some environment variables under my computer - system - advanced - environment variables well, if you do it that way, you might need to close and re-open the console afterwards .. But make.exe seems to ignore them, is there any command to add them manually during compile? I'm stuck here... try make install FPCDIR=/full/path/to/fpc-source/ p.s. yes there's a mailing list too where ? Here: http://tech.groups.yahoo.com/group/Indy-Dev-Public/ thanks regards Burkhard ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Suggestion for change: Overly strict check
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 implemented to avoid bad code. However, it's not entirely obvious why this is supposed to help. Please consider this example: type tfoo = class(tbar) private public procedure Frob(); procedure Wait(delay: integer); procedure ReadStuff(buffer: tbuffer; wait: boolean); end; Even in delphi, I allways use(d) procedure ReadStuff(aBuffer: tbuffer; aWait: boolean); .. This won't help you, but you asked for thought. And my thoughts are: I like it the way it is. regards Burkhard ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Some details on BeginThread problem
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 debugging..
From rtl/linux/tthread.inc line 189:
{ TThread }
constructor TThread.Create(CreateSuspended: Boolean;
const StackSize: SizeUInt =
DefaultStackSize);
begin
// lets just hope that the user doesn't create a thread
// via BeginThread and creates the first TThread Object in there!
InitThreads;
...
I don't have mac os, no idea, if this applies there, too. Just thought,
I should mention this ;-)
regards
Burkhard
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Propose: change TComponent.Tag from longint to PtrInt
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 make the tag something huge for years to come, like Int64. The idea with hidden union is nice tho. But you'll need to know how to stream it precisely and there's also endianness to take care of then. I've been following the discussion, and the tag property will remain what it is: a 32-bit integer. It was introduced by Delphi to mimic the Tag property which exists in VB, to allow it to be used in case statements. Changing it will probably cause more problems than it will solve. In casu: Typecasting 'Tag' to a pointer is a non-portable, ugly hack and we should not encourage such hacks. If you want to store objects, use a TCollection, and store TCollectionItem.ID in the component tag. ID is a unique identifier, even when elements are added and removed from the collection. Slightly more work, but clean and portable. Michael. In many situations, the collection would be overkill, so I'd also opt for the new public property UserData : pointer or better TagPtr : pointer. This would make it harder to create code, that also compiles with delphi, but that doesn't bother me ;-) Anyway, if one needs to compile with delphi, one could continue to use pointer(tag), as delphi is 32-bit only anyway ... This way the user has the choice to write code that compiles with fpc32+delphi or fpc32+fpc64 regards Burkhard ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] unable to make all fpc trunk r4410
* 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 - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] unable to make all fpc trunk r4410
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 4410 fails. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] patch to make math.pp more D7 compatible
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 of type float as in D7, they are also type extended. Only for minvalue and maxvalue, I changed the result also to double, because it doesn't make sense to have higher precision here and D7 does the same. This changes might be problematic on platforms where double is not supported (if any), but as there are other functions using double in math.pp, I didn't care about this. 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 double will map it an appropriate type anyways. ok. Thanks! ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] patch to make math.pp more D7 compatible
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 double will map it an appropriate type
anyways.
Hmm. This possible breaks numlib. I believe I changed that to use the
float type also, since it already was switchable depending on real
type.
Float didn't change.
If I find some time tomorrow, I'll try to make a new patch to have the
stats functions overloaded for array of {single,double,extended} and
put the appropriate ifdefs around them.
Regards,
Burkhard
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] patch to make math.pp more D7 compatible
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 double, because it doesn't make sense to
have higher precision here and D7 does the same.
This changes might be problematic on platforms where double is not
supported (if any), but as there are other functions using double in
math.pp, I didn't care about this.
Regards
Burkhard
Index: rtl/objpas/math.pp
===
--- rtl/objpas/math.pp (Revision 4157)
+++ rtl/objpas/math.pp (Arbeitskopie)
@@ -300,57 +300,57 @@
{ statistical functions }
-function mean(const data : array of float) : float;
-function sum(const data : array of float) : float;
-function mean(const data : PFloat; Const N : longint) : float;
-function sum(const data : PFloat; Const N : Longint) : float;
+function mean(const data : array of double) : float;
+function sum(const data : array of double) : float;
+function mean(const data : PDouble; Const N : longint) : float;
+function sum(const data : PDouble; Const N : Longint) : float;
function sumInt(const data : PInt64;Const N : longint) : Int64;
function sumInt(const data : array of Int64) : Int64;
-function sumofsquares(const data : array of float) : float;
-function sumofsquares(const data : PFloat; Const N : Integer) : float;
+function sumofsquares(const data : array of double) : float;
+function sumofsquares(const data : PDouble; Const N : Integer) : float;
{ calculates the sum and the sum of squares of data }
-procedure sumsandsquares(const data : array of float;
+procedure sumsandsquares(const data : array of Double;
var sum,sumofsquares : float);
-procedure sumsandsquares(const data : PFloat; Const N : Integer;
+procedure sumsandsquares(const data : PDouble; Const N : Integer;
var sum,sumofsquares : float);
-function minvalue(const data : array of float) : float;
+function minvalue(const data : array of Double) : Double;
function minvalue(const data : array of integer) : Integer;
-function minvalue(const data : PFloat; Const N : Integer) : float;
+function minvalue(const data : PDouble; Const N : Integer) : Double;
function MinValue(const Data : PInteger; Const N : Integer): Integer;
-function maxvalue(const data : array of float) : float;
+function maxvalue(const data : array of Double) : Double;
function maxvalue(const data : array of integer) : Integer;
-function maxvalue(const data : PFloat; Const N : Integer) : float;
+function maxvalue(const data : PDouble; Const N : Integer) : Double;
function maxvalue(const data : PInteger; Const N : Integer) : Integer;
{ calculates the standard deviation }
-function stddev(const data : array of float) : float;
-function stddev(const data : PFloat; Const N : Integer) : float;
+function stddev(const data : array of Double) : float;
+function stddev(const data : PDouble; Const N : Integer) : float;
{ calculates the mean and stddev }
-procedure meanandstddev(const data : array of float;
+procedure meanandstddev(const data : array of Double;
var mean,stddev : float);
-procedure meanandstddev(const data : PFloat;
+procedure meanandstddev(const data : PDouble;
Const N : Longint;var mean,stddev : float);
-function variance(const data : array of float) : float;
-function totalvariance(const data : array of float) : float;
-function variance(const data : PFloat; Const N : Integer) : float;
-function totalvariance(const data : PFloat; Const N : Integer) : float;
+function variance(const data : array of Double) : float;
+function totalvariance(const data : array of Double) : float;
+function variance(const data : PDouble; Const N : Integer) : float;
+function totalvariance(const data : PDouble; Const N : Integer) : float;
{ returns random values with gaussian distribution }
function randg(mean,stddev : float) : float;
{ I don't know what the following functions do: }
-function popnstddev(const data : array of float) : float;
-function popnstddev(const data : PFloat; Const N : Integer) : float;
-function popnvariance(const data : PFloat; Const N : Integer) : float;
-function popnvariance(const data : array of float) : float;
-procedure momentskewkurtosis(const data : array of float;
+function popnstddev(const data : array of Double) : float;
+function popnstddev(const data : PDouble; Const N : Integer) : float;
+function popnvariance(const data : PDouble; Const N : Integer) : float;
+function popnvariance(const data : array of Double) : float;
+procedure momentskewkurtosis(const data : array of Double;
var m1,m2,m3,m4,skew,kurtosis : float);
-procedure momentskewkurtosis(const data : PFloat; Const N : Integer;
+procedure momentskewkurtosis(const data : PDouble; Const N : Integer;
var m1,m2,m3,m4,skew,kurtosis : float);
{ geometrical function }
{ returns the
Re: [fpc-devel] wrong results of function align
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-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] wrong results of function align
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:
p:=getmem(MyAry,sizeof(MyAry)+4096); p:=align(p,4096);
IMO align($8001,$1000) should give $80001000, but gives $80002000.
Attached is a testcase and a patch.
Index: rtl/inc/generic.inc
===
--- rtl/inc/generic.inc (Revision 4059)
+++ rtl/inc/generic.inc (Arbeitskopie)
@@ -990,7 +990,7 @@
-function align(addr : PtrInt;alignment : PtrInt) : PtrInt;{$ifdef SYSTEMINLINE}inline;{$endif}
+function align(addr : PtrUInt;alignment : PtrUInt) : PtrUInt;{$ifdef SYSTEMINLINE}inline;{$endif}
begin
if addr mod alignment0 then
result:=addr+(alignment-(addr mod alignment))
@@ -999,10 +999,10 @@
end;
-function align(addr : Pointer;alignment : PtrInt) : Pointer;{$ifdef SYSTEMINLINE}inline;{$endif}
+function align(addr : Pointer;alignment : PtrUInt) : Pointer;{$ifdef SYSTEMINLINE}inline;{$endif}
begin
-if PtrInt(addr) mod alignment0 then
- result:=pointer(addr+(alignment-(PtrInt(addr) mod alignment)))
+if PtrUInt(addr) mod alignment0 then
+ result:=pointer(addr+(alignment-(PtrUInt(addr) mod alignment)))
else
result:=addr;
end;
Index: rtl/inc/systemh.inc
===
--- rtl/inc/systemh.inc (Revision 4059)
+++ rtl/inc/systemh.inc (Arbeitskopie)
@@ -434,8 +434,8 @@
Function Swap (X : QWord) : QWord;{$ifdef SYSTEMINLINE}inline;{$endif}[internconst:fpc_in_const_swap_qword];
Function swap (X : Int64) : Int64;{$ifdef SYSTEMINLINE}inline;{$endif}[internconst:fpc_in_const_swap_qword];
-Function Align (Addr : PtrInt; Alignment : PtrInt) : PtrInt;{$ifdef SYSTEMINLINE}inline;{$endif}
-Function Align (Addr : Pointer; Alignment : PtrInt) : Pointer;{$ifdef SYSTEMINLINE}inline;{$endif}
+Function Align (Addr : PtrUInt; Alignment : PtrUInt) : PtrUInt;{$ifdef SYSTEMINLINE}inline;{$endif}
+Function Align (Addr : Pointer; Alignment : PtrUInt) : Pointer;{$ifdef SYSTEMINLINE}inline;{$endif}
Function Random(l:longint):longint;
Function Random(l:int64):int64;
program writeroundtest;
{$mode objfpc}{$H+}
var
ap1,ap2 : pointer;
function UINTalign(addr : Pointer;alignment : PtrUInt) : Pointer;
begin
if PtrUInt(addr) mod alignment0 then
result:=pointer(addr+(alignment-(PtrUInt(addr) mod alignment)))
else
result:=addr;
end;
begin
ap1:=pointer($7001);
ap2:=pointer($8001);
writeln(hexstr(ap1),' -- ',hexstr(align(ap1,$1000)));
writeln(hexstr(ap2),' -- ',hexstr(align(ap2,$1000)));
writeln(hexstr(ap2),' -- ',hexstr(UINTalign(ap2,$1000)));
end.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] wrong results of function align
.. 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 align in compiler/cutils.pas align($7001,4) - 7004 //correct align($8001,4) - 7FFC //wrong function aligntoptr in rtl/objpas/typinfo.pp seems to be the only one doing it correctly!! Regards, Burkhard ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] svn trunc doesn't compile since rev 2949
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 `/home/bork/FreePascal/fpctrunk/fcl/db' [..] jonas? regards, burkhard ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] svn trunc doesn't compile since rev 2949
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
