Re: [fpc-devel] TDataset.ClearBuffers change in svn revision 3138
On Mon, 2006-04-03 at 21:29 -0300, Luiz Americo Pereira Camara wrote: In revision 3138 TDataset.Clearbuffers call InternalInitRecord to empty the ActiveBuffer. I have two comments: - In DoInsertAppend InternalInitRecord will be called twice: one through ClearBuffers and other through InitRecord Yes, but twice for very different records, and only if it's an append. That's because 'append' effectively does a 'last' and then 'insert'. That it's called for the insert is logical. For the 'last'-part, see below: - ClearBuffers is called in First, Last, Resync: in this situations is desired to clear the ActiveBuffer? It is in the case of Resync. If a 'fuzzy resync' occurs that is most often because that the dataset is empty all of a sudden. For example if the last record is deleted. Or, for sqldb, if there are records added to a empty dataset, and cancelupdates is called. If InternalInitRecord isn't called then, you will still see the data of the latest record before the dataset became empty. If that record isn't cleared with InternalInitRecord, it will look like if there is still data. (although IsEmpty is true) So I've first added InternalInitRecord to Resync, but then I saw ClearBuffers and found it more logical to do it there. Since ClearBuffers clears the buffers if the dataset gets empty. Only I haven't thought about it that First and Last also calls it. On the other hand, if one does a 'first' and the dataset seems to be empty, the active record should be cleared. But I think you'll never encounter this problem, since the dataset most probably already was empty before the 'last' or 'first' calls... So, I think calling it in ClearBuffers is more logical, doing it in resync is somewhat better for performance? Joost. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Which version of fpc has the new internal linker?
Which version of FPC has the new internal linker? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Hitting bug 4733
Hello, I am trying to compile a Firebird UDF library with fpc 2.0.0 under on the amd64 architecture (precisely: ubuntu dapper preview release), but unfortunately I hit bug 4733... That is: The code compiles fine, but fails to link, here below the complete error: [EMAIL PROTECTED]:~/subversion/linux/UdfLib$ make fpc -Sd UdfLib.dpr Free Pascal Compiler version 2.0.0 [2005/05/15] for x86_64 Copyright (c) 1993-2005 by Florian Klaempfl Target OS: Linux for x86-64 Compiling UdfLib.dpr Assembling udflib Linking libUdfLib.so /usr/bin/ld: /usr/lib/fpc/2.0.0/units/x86_64-linux/rtl/system.o: relocation R_X86_64_32S against `TC_SYSTEM_ISMULTITHREAD' can not be used when making a shared object; recompile with -fPIC /usr/lib/fpc/2.0.0/units/x86_64-linux/rtl/system.o: could not read symbols: Bad value UdfLib.dpr(86) Error: Error while linking Error: /usr/bin/ppcx64 returned an error exitcode (normal if you did not specifiy a source file to be compiled) make: *** [all] Error 1 [EMAIL PROTECTED]:~/subversion/linux/UdfLib$ Now, brave as I am I checked out svn and tried to build the beast, with the -fPIC directive, but I failed miserably because I could simply not figure out where to set that flag. I tried different makefiles but none seemed to make it for me... (Generally, I am not even sure compiling with -fPIC will resolve my problem...) I would be very thankful for any hint on how to get the code to link :-) Best regards, Yves p.s. I should mention that the mentioned UDF library builds, links and runs fine one the i386 platform (Tested on debian sarge and sid) The debs I used to install fpc are these: ftp://ftp.freepascal.org/pub/fpc/dist/i386-linux-2.0.0/deb/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] TDataset.ClearBuffers change in svn revision 3138
Joost van der Sluis escreveu: On Mon, 2006-04-03 at 21:29 -0300, Luiz Americo Pereira Camara wrote: In revision 3138 TDataset.Clearbuffers call InternalInitRecord to empty the ActiveBuffer. I have two comments: - In DoInsertAppend InternalInitRecord will be called twice: one through ClearBuffers and other through InitRecord Yes, but twice for very different records, and only if it's an append. That's because 'append' effectively does a 'last' and then 'insert'. That it's called for the insert is logical. For the 'last'-part, see below: - ClearBuffers is called in First, Last, Resync: in this situations is desired to clear the ActiveBuffer? It is in the case of Resync. If a 'fuzzy resync' occurs that is most often because that the dataset is empty all of a sudden. For example if the last record is deleted. Or, for sqldb, if there are records added to a empty dataset, and cancelupdates is called. If InternalInitRecord isn't called then, you will still see the data of the latest record before the dataset became empty. If that record isn't cleared with InternalInitRecord, it will look like if there is still data. (although IsEmpty is true) So I've first added InternalInitRecord to Resync, but then I saw ClearBuffers and found it more logical to do it there. Since ClearBuffers clears the buffers if the dataset gets empty. Only I haven't thought about it that First and Last also calls it. On the other hand, if one does a 'first' and the dataset seems to be empty, the active record should be cleared. But I think you'll never encounter this problem, since the dataset most probably already was empty before the 'last' or 'first' calls... So, I think calling it in ClearBuffers is more logical, doing it in resync is somewhat better for performance? I understood that the only place that it's necessary is inside Resync. If so i am in favour of adding directly to it since won't hurt the readability, the functionality or the code size since is only a line of code. The performance will suffer mainly because of the call inside InsertAppend (more or less depending of the TDataset implementation) . Anyway i think we should keep TDataset as fast as possible. Luiz ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
