Re: [fpc-devel] Recent changes to TField.SetData
Am 04.04.2011 07:29, schrieb Michael Van Canneyt: On Mon, 4 Apr 2011, LacaK wrote: But It seems to me, that DataChanged is now called 2 times First in TDataSet descendants in SetFieldData method (see bufdataset.pas, dbf.pas, paradox.pp, meds.pp) and second in above mentioned place. So it would be good remove this call from TDataSet descendants. For example for bufdataset.pas: 1860 if not (State in [dsCalcFields, dsFilter, dsNewValue]) then 1861 DataEvent(deFieldChange, Ptrint(Field)); Hm. No, we'll remove the call from TField. There may be other descendants (AnyDac, Zeos and whatnot) that also call DataEvent and OnValidate, and we cannot apply this change on them. Thanks. For example the code in tmsebufdataset: procedure tmsebufdataset.setfielddata(field: tfield; buffer: pointer); var po1: pointer; datasize: integer; begin field.validate(buffer); po1:= getfieldbuffer(field,buffer = nil,datasize); if buffer nil then begin move(buffer^,po1^,datasize); end else begin fillchar(po1^,datasize,0); end; fieldchanged(field); end; Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Behavior of conversion between vardate variants and string in fpc and delphi
Running this code in Delphi 7 gives the exception below:
var
V: Variant;
D: TDateTime;
begin
ShortDateFormat := 'dd/mm/'; // the problem occurs regardless of
the format option
V := '20/04/2011';
D := V;
Memo1.Lines.Add('Date: ' + DateToStr(D)); // required to avoid dead
code elimination
end;
raised exception class EVariantTypeCastError with message 'Could not
convert variant of type (String) into type (Double)'
Can someone check with more recent Delphi if this is still true?
In DelphiXE:
raised exception class EVariantTypeCastError with message 'Could not
convert variant of type (UnicodeString) into type (Double)'
Laco.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Behavior of conversion between vardate variants and string in fpc and delphi
So, what should be done?
1) Be totally compatible with Delphi: convert date to string with
hardcoded format and raise exception when doing the conversion back?
2) Use the hardcoded format used to convert from vardate variant to
string and vice versa?
3) Use shortdateformat to convert from vardate variant to string and
vice versa?
Point 3 sounds to me as best and logical.
This code in DelphiXE:
ShortDateFormat := 'dd#mm#'; // the problem occurs regardless of
the format option
DateSeparator:='#';
V := '20#04#2011';
v1:=varAsType(V, varDate);
D:=v1;
Writeln('Date: ' + DateToStr(D));
Outputs:
Date: 20#04#2011
So it seems, that DelphiXe also uses ShortDateFormat, DateSeparator
Laco.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Changes in Makefile-system
2011/4/1 Joost van der Sluis jo...@cnoc.nl: Hi all, I've just committed a change in the Makefiles for the fcl-web package. The Makefile now calls fpmake to build and install the package. It's a first test, so please try and report any problems you have when building the fcl-web package. (Or all packages, or just a complete fpc-checkout) I'll try to fix them as soon as possible. Cross compiling is broken, the crosscompiler is used to compile fpmake and the resulting fpmake is not for the host but the target os/cpu. c:/lazarus/source/fpcbuild/trunk/fpcsrc/compiler/ppcrossarm.exe -Twince -Parm -XParm-wince- -Xr -Ur -Xs -O2 -n -S2h -FuC:/lazarus/source/fpcbuild/trunk/fpcsrc/rtl/units/arm-wince -FDc:\lazarus\source\binutils\arm-wince -FE. -FUunits/arm-wince -darm -dRELEASE src/fastcgi.pp make.exe[2]: Leaving directory `C:/lazarus/source/fpcbuild/trunk/fpcsrc/packages/fastcgi' c:/lazarus/source/fpcbuild/trunk/install/binw32/make.exe -C fcl-web all make.exe[2]: Entering directory `C:/lazarus/source/fpcbuild/trunk/fpcsrc/packages/fcl-web' c:/lazarus/source/fpcbuild/trunk/fpcsrc/compiler/ppcrossarm.exe fpmake.pp -Twince -Parm -XParm-wince- -Xr -Ur -Xs -O2 -n -FuC:/lazarus/source/fpcbuild/trunk/fpcsrc/rtl/units/arm-wince -FuC:/lazarus/source/fpcbuild/trunk/fpcsrc/packages/hash/units/arm-wince -FuC:/lazarus/source/fpcbuild/trunk/fpcsrc/packages/paszlib/units/arm-wince -FuC:/lazarus/source/fpcbuild/trunk/fpcsrc/packages/fcl-process/units/arm-wince -FuC:/lazarus/source/fpcbuild/trunk/fpcsrc/packages/fpmkunit/units/arm-wince -FDc:\lazarus\source\binutils\arm-wince -FE. -FUunits/arm-wince -darm -dRELEASE ./fpmake build --localunitdir=../.. --globalunitdir=.. --os=wince --cpu=arm -o -Twince -o -Parm -o -XParm-wince- -o -Xr -o -Ur -o -Xs -o -O2 -o -n -o -FuC:/lazarus/source/fpcbuild/trunk/fpcsrc/rtl/units/arm-wince -o -FuC:/lazarus/source/fpcbuild/trunk/fpcsrc/packages/hash/units/arm-wince -o -FuC:/lazarus/source/fpcbuild/trunk/fpcsrc/packages/paszlib/units/arm-wince -o -FuC:/lazarus/source/fpcbuild/trunk/fpcsrc/packages/fcl-process/units/arm-wince -o -FuC:/lazarus/source/fpcbuild/trunk/fpcsrc/packages/fpmkunit/units/arm-wince -o -FDc:\lazarus\source\binutils\arm-wince -o -FE. -o -FUunits/arm-wince -o -darm -o -dRELEASE --compiler=c:/lazarus/source/fpcbuild/trunk/fpcsrc/compiler/ppcrossarm.exe process_begin: CreateProcess(C:\lazarus\source\fpcbuild\trunk\fpcsrc\packages\fcl-web\fpmake.exe, ./fpmake build --localunitdir=../.. --globalunitdir=.. --os=wince --cpu=arm -o -Twince -o -Parm -o -XParm-wince- -o -Xr -o -Ur -o -Xs -o -O2 -o -n -o -FuC:/lazarus/source/fpcbuild/trunk/fpcsrc/rtl/units/arm-wince -o -FuC:/lazarus/source/fpcbuild/trunk/fpcsrc/packages/hash/units/arm-wince -o -FuC:/lazarus/source/fpcbuild/trunk/fpcsrc/packages/paszlib/units/arm-wince -o -FuC:/lazarus/source/fpcbuild/trunk/fpcsrc/packages/fcl-process/units/arm-wince -o -FuC:/lazarus/source/fpcbuild/trunk/fpcsrc/packages/fpmkunit/units/arm-wince -o -FDc:\lazarus\source\binutils\arm-wince -o -FE. -o -FUunits/arm-wince -o -darm -o -dRELEASE --compiler=c:/lazarus/source/fpcbuild/trunk/fpcsrc/compiler/ppcrossarm.exe, ...) failed. make (e=193): Error 193make.exe[2]: *** [all] Error 193 make.exe[2]: Leaving directory `C:/lazarus/source/fpcbuild/trunk/fpcsrc/packages/fcl-web' make.exe[1]: *** [fcl-web_all] Error 2 Vincent ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Changes in Makefile-system
In our previous episode, Vincent Snijders said: Hi all, I've just committed a change in the Makefiles for the fcl-web package. The Makefile now calls fpmake to build and install the package. It's a first test, so please try and report any problems you have when building the fcl-web package. (Or all packages, or just a complete fpc-checkout) I'll try to fix them as soon as possible. Cross compiling is broken, the crosscompiler is used to compile fpmake and the resulting fpmake is not for the host but the target os/cpu. For me normal win32 building doesn't even work. I suspect setting -O- in the OPTS is the cause for this, fpmake transforming that into a -o no param or so. make[3]: Entering directory `d:/repo/fpc/packages/fcl-web' d:/repo/fpc/compiler/ppc386.exe fpmake.pp -Ur -Xs -O2 -n -Fud:/repo/fpc/rtl/units/i386-win32 -Fud:/repo/fpc/packages/hash/units/i386-win32 -Fud:/repo/fpc/packages/paszlib/units/i386-win32 -Fud:/repo/fpc/packages/fcl-process/units/i386-win32 -Fud:/repo/fpc/packages/fpmkunit/units/i386-win32 -FE. -FUunits/i386-win32 -O-gl -dUse_MINGW_GDB -di386 -dRELEASE ./fpmake build --localunitdir=../.. --globalunitdir=.. --os=win32 --cpu=i386 -o -Ur -o -Xs -o -O2 -o -n -o -Fud:/repo/fpc/rtl/units/i386-win32 -o -Fud:/repo/fpc/packages/hash/units/i386-win32 -o -Fud:/repo/fpc/packages/paszlib/units/i386-win32 -o -Fud:/repo/fpc/packages/fcl-process/units/i386-win32 -o -Fud:/repo/fpc/packages/fpmkunit/units/i386-win32 -o -FE. -o -FUunits/i386-win32 -o -O-o -gl -o -dUse_MINGW_GDB -o -di386 -o -dRELEASE --compiler=d:/repo/fpc/compiler/ppc386.exe -o -XX -CX '.' is not recognized as an internal or external command, operable program or batch file. make[3]: *** [smart] Error 1 make[3]: Leaving directory `d:/repo/fpc/packages/fcl-web' make[2]: *** [fcl-web_smart] Error 2 make[2]: Leaving directory `d:/repo/fpc/packages' make[1]: *** [packages_smart] Error 2 make[1]: Leaving directory `d:/repo/fpc' make: *** [build-stamp.i386-win32] Error 2 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Recent changes to TField.SetData
On Mon, 4 Apr 2011, LacaK wrote: Michael Van Canneyt wrote / napísal(a): On Mon, 4 Apr 2011, LacaK wrote: Hi, This fix http://svn.freepascal.org/cgi-bin/viewvc.cgi/trunk/packages/fcl-db/src/base/fields.inc?r1=17199r2=17220 fixes mising call to TField.Validate (before data are written into record buffer) and adds also call to TField.DataChanged (after data are written) But It seems to me, that DataChanged is now called 2 times First in TDataSet descendants in SetFieldData method (see bufdataset.pas, dbf.pas, paradox.pp, meds.pp) and second in above mentioned place. So it would be good remove this call from TDataSet descendants. For example for bufdataset.pas: 1860 if not (State in [dsCalcFields, dsFilter, dsNewValue]) then 1861 DataEvent(deFieldChange, Ptrint(Field)); Hm. No, we'll remove the call from TField. There may be other descendants (AnyDac, Zeos and whatnot) that also call DataEvent and OnValidate, and we cannot apply this change on them. Yes it seems, that we must do it in this way. (Although I do not understand why Borland introduces this strange behavior) Then please move approprate code at least into TCustomBufDataset.SetFieldData Thanks This code was already there. Should the 'Validate' code be moved there too ? Michael.___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Behavior of conversion between vardate variants and string in fpc and delphi
On 4/4/2011 04:34, LacaK wrote: So, what should be done? 1) Be totally compatible with Delphi: convert date to string with hardcoded format and raise exception when doing the conversion back? 2) Use the hardcoded format used to convert from vardate variant to string and vice versa? 3) Use shortdateformat to convert from vardate variant to string and vice versa? Point 3 sounds to me as best and logical. Agree. my second patch does that Luiz ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] OpenCL/Cuda/PTX Support ?!?
Hello, I tried searching the archives manually but this is a bit time consuming, I also tried the search function on the website but it seems broken. Anyway my question is the following: Are there any plans to add OpenCL/CUDA/PTX support for the future ? With this question I do not mean DLL api/loading support... but pascal language/compiler to ptx assembler support. PTX is the instruction set for OpenCL/CUDA, especially CUDA (for nvidia cards and perhaps other manufacturers in future). PTX seems to have become mature enough with the basic functionalities such as integer and floating support and branching/looping support. So I envision a free pascal compiler which can be simply used to compile pascal code to PTX code (assembler/intermediate code). This PTX code (kernels?) can then be used by pascal applications to feed it to the CUDA/OpenCL dll's/api's for execution. So in short this would make pascal an alternative language for writing OpenCL/CUDA kernels. Bye, Skybuck. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Adding a new assembler to Free Pascal Compiler
Hello, I would like to experiment with the pascal programming language at the binary/assembler/machine level. For example compile pascal sources to virtual machine instruction sets. I took a look at the free pascal sources and there seem to be some assemblers inside the folders. I see classes with names like TExternalAssember and TInternalAssember I also see files called: aasmcpu, aasmtai. Some processor architectures seem to derive from TExternalAssembler but then still implement lot's of stuff themselfes inside the class instead of calling a real external assembler (perhaps a trick ? ;)) This is confusing me a little bit so I have some question about what free pascal exaclty is, how it functions and what it does and can do or cannot do: So some questions: 1. Are all assemblers compiled into the final free pascal executable ? Or is only one assembler possible which is selected by conditional defines ? Suppose the answer to question 1 is: yes, multiple assemblers are supported. (This seems to be the case since free pascal has the -a and -A directive with different asm output options... (?!?)) Then my next question is 2: 2. This would mean free pascal is by default a cross compiler, which can cross-compile to any assembly/intermediate code. So then my main/subject question: How to add a new assember to free pascal compiler makes sense... Assuming it makes sense I continue my story: I searched the documentation about how to do this... but there seems to be no documentation for this ? So if somebody could create some (short?) documentation for this or some tips how/where to start and how to proceed that would be helpfull. Perhaps a simple dummy assembler or template might be nice... concerning this adding for a new assembler my main question would be where to add this unit, how to make free pascal notice it and use it and such ? Where to add the compiler directive and perhaps initialization and finalization of classes/create/destroy that sort of thing. 3. Assuming free pascal is a cross compiler, and looking at the code... it seems free pascal actually compiles pascal code into an abstract assembler structure, is this indeed correct ? Can free pascal be considered a pascal to abstract assembler compiler ? (which would be pretty cool) (which ultimately gets assembled into real assembler...) So in short what I am looking for is a pascal compiler which takes care of all the work like lexing/tokenizing/parsing/parse tree/syntax tree/symantec checks/perhaps even optimizing the intermediate code and gives me something to work with like a syntax tree or some form of abstract assembler (structures) like free pascal seems to do... To me it seems free pascal could be the correct choice... either by modifieing it or by extending it... So if I have to modify it... I would for example modify the intel or powerpc or sparc source code and pretend it's my own thing... but it would probably be better if I can stuff my own assembler/platform/units into it to start from scratch just to play nice with free pascal and prevent confusing things later on... So I think I need to some help with: is this possible and how to do it/documentation/short tutorial/some tips ?!? Bye, Skybuck. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Adding a redcode assembler to Free Pascal Compiler
Hello, I kinda forget to mention something in my previous posting to this mailing list, but perhaps it should go into a seperate thread anyway: As I mentioned in the previous posting with subject: Adding a new assembler to Free Pascal Compiler... I am interested in using free pascal compiler to create support for virtual machines and perhaps new hardware in the future. As a learning exercise I would like to start with writing a little redcode assembler for Free Pascal Compiler to be able to compile Pascal Source Code to Redcode/PMARS95 instructions/assembler. (Redcode is the assembly code/language for PMARS95 which is the virtual machine). I already have a virtual machine for the redcode assembly/instructions, there is also the open source pmars virtual machine which you can have a look at to see what I am writing about ;) So I wonder what is involved in supporting a new platform... be it real hardware or virtual machines. One thing which comes to mind is the RTL ? Do new targets (as it's called ?) require their own RTL as well ? I did see a mention about a dummy RTL as a possibility (Not sure if that's needed but I would guess so ;)). So it would be cool if free pascal compiler could compile pascal sources into redcode assembly, which can then be further compiled by the PMARS executable/assembler. So I just need free pascal compiler to output redcode assembly... it probably doesn't have to link anything or assemble anything further, though a little bit of linking support for using multiple pascal sources would be cool as well... not sure how that would work at assembly level... maybe that's a good question too... would free pascal compiler simply perform some kind of linking/syntax checking for uses clausule based on assembly files (*.s) ? Or perhaps it does it via interface/header files ? (probably last one). So as long as all headers are present then assembly of those files don't matter and compiler knows what it's doing... So linking of assemblies only happens later by other tools (?). So for example: a call to a routine of some unit is outputted as a call to a label... and then the external assembler tool will hopefully know what to do with those labels ;) (User will probably have to supply multiple assembly files in such a case ;) that probably what make files are for ;)) Bye, Skybuck. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Recent changes to TField.SetData
On 4/4/2011 10:28, michael.vancann...@wisa.be wrote: On Mon, 4 Apr 2011, LacaK wrote: Michael Van Canneyt wrote / napísal(a): On Mon, 4 Apr 2011, LacaK wrote: Then please move approprate code at least into TCustomBufDataset.SetFieldData Thanks This code was already there. Should the 'Validate' code be moved there too ? Yes. TDataset descendants are responsible to calling Validate, e.g., zeos call it inside TZAbstractRODataset.SetFieldData. One of the reasons of letting descendants call it it's too improve granularity so Validate can be called in the middle of the routine, as is in zeos, instead to force the call before the TDataset routine. Luiz ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] helper feature finished
05.04.2011 3:51, Sven Barth wrote: Both class helpers and record helpers are implemented and work as Delphi compatible as reasonably possible. Congratulations. Some notes regarding the tests: * three record helper tests (trhlp*) fail, because nested types are not supported by (advanced) records (two should fail nevertheless, because they try to access (strict) private helpers, the third should succeed) Nested types in records are supported actually. Maybe you found a bug? * three more record helper tests fail, because the abbreviated syntax to access default properties is not supported Indeed, I forgot about this feature during the implementation. Regarding performance: For projects that don't use helper types (like currently all code provided by FPC) there isn't much speed difference, because 1. I check whether a symtable contains a helper at all (using the new symtable options) before searching through it when it's pushed on the symtable stack 2. I check whether the current module contains helped types at all We probably can extend these tricks for other types and may be speedup the compiler. I think your branch should be reviewed either by Florian or by Jonas before the merge. Best regards, Paul Ishenin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Delphi 64bit compiler sneak peak available now
https://forums.codegear.com/thread.jspa?threadID=52117tstart=0 We can check it out and do some comparisons now. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Adding a new assembler to Free Pascal Compiler
Answering my own question ;)
I guess the answer to my question is more or less the same as the following
question:
How to add a new target to free pascal compiler.
And I found this webpage which explains it a bit:
http://wiki.freepascal.org/Porting_Free_Pascal#Adding_a_new_target
I'll quote webpage here in case it ever goes lost ;)
Bellow is a example of how a new target is added. This Patch was responsible
for adding SymbianOS target to the compiler. Be careful that this adds a
i386-symbian target. If your target is for another architecture of course
you should change the files on the directories for your particular
architecture.
Index: compiler/compiler.pas
===
--- compiler/compiler.pas (revision 6039)
+++ compiler/compiler.pas (working copy)
@@ -107,6 +107,9 @@
{$ifdef win32}
,i_win
{$endif win32}
+{$ifdef symbian}
+ ,i_symbian
+{$endif symbian}
;
function Compile(const cmd:string):longint;
Index: compiler/i386/cputarg.pas
===
--- compiler/i386/cputarg.pas (revision 6039)
+++ compiler/i386/cputarg.pas (working copy)
@@ -71,6 +71,9 @@
{$ifndef NOTARGETWATCOM}
,t_watcom
{$endif}
+{$ifndef NOTARGETSYMBIAN}
+ ,t_symbian
+{$endif}
{**
Assemblers
Index: compiler/systems.pas
===
--- compiler/systems.pas (revision 6039)
+++ compiler/systems.pas (working copy)
@@ -136,7 +136,9 @@
system_x86_64_embedded,{ 55 }
system_mips_embedded, { 56 }
system_arm_embedded, { 57 }
- system_powerpc64_embedded { 58 }
+ system_powerpc64_embedded, { 58 }
+ system_i386_symbian, { 59 }
+ system_arm_symbian { 60 }
);
tasm = (as_none
Index: rtl/Makefile.fpc
===
--- rtl/Makefile.fpc (revision 6038)
+++ rtl/Makefile.fpc (working copy)
@@ -28,6 +28,7 @@
dirs_solaris=solaris
dirs_gba=gba
dirs_nds=nds
+dirs_symbian=symbian
[install]
fpcpackage=y
Index: utils/fpcm/fpcmake.ini
===
--- utils/fpcm/fpcmake.ini (revision 6038)
+++ utils/fpcm/fpcmake.ini (working copy)
@@ -908,6 +908,12 @@
SHORTSUFFIX=gba
endif
+# Symbian OS
+ifeq ($(OS_TARGET),symbian)
+SHAREDLIBEXT=.dll
+SHORTSUFFIX=symbian
+endif
+
else
# long version for 1.0.x - target specific extensions
Index: utils/fpcm/fpcmmain.pp
===
--- utils/fpcm/fpcmmain.pp (revision 6038)
+++ utils/fpcm/fpcmmain.pp (working copy)
@@ -70,7 +70,7 @@
o_linux,o_go32v2,o_win32,o_os2,o_freebsd,o_beos,o_netbsd,
o_amiga,o_atari, o_solaris, o_qnx, o_netware, o_openbsd,o_wdosx,
o_palmos,o_macos,o_darwin,o_emx,o_watcom,o_morphos,o_netwlibc,
-o_win64,o_wince,o_gba,o_nds,o_embedded
+o_win64,o_wince,o_gba,o_nds,o_embedded,o_symbian
);
TTargetSet=array[tcpu,tos] of boolean;
@@ -88,14 +88,14 @@
'linux','go32v2','win32','os2','freebsd','beos','netbsd',
'amiga','atari','solaris', 'qnx', 'netware','openbsd','wdosx',
'palmos','macos','darwin','emx','watcom','morphos','netwlibc',
-'win64','wince','gba','nds','embedded'
+'win64','wince','gba','nds','embedded','symbian'
);
OSSuffix : array[TOS] of string=(
'_linux','_go32v2','_win32','_os2','_freebsd','_beos','_netbsd',
'_amiga','_atari','_solaris', '_qnx',
'_netware','_openbsd','_wdosx',
'_palmos','_macos','_darwin','_emx','_watcom','_morphos','_netwlibc',
-'_win64','_wince','_gba','_nds','_embedded'
+'_win64','_wince','_gba','_nds','_embedded','_symbian'
);
{ This table is kept OS,Cpu because it is easier to maintain (PFV) }
@@ -126,7 +126,8 @@
{ wince}( true, false, false, false, false, true, false),
{ gba} ( false, false, false, false, false, true, false),
{ nds} ( false, false, false, false, false, true, false),
-{ embedded }( true, true, true, true, true, true, true)
+{ embedded }( true, true, true, true, true, true, true),
+{ symbian } ( true, false, false, false, false, true, false)
);
type
You will also need to add a i_target.pas and t_target.pas files to the
compiler directory. Just copy an existing file for a similar platform and
start working from there.
If you want your target to use an internal linker (ELF, COFF, etc.) you need
to add your target to that one, too. For the target i386-nativent the
following change was done in the COFF output generator:
Index: compiler/ogcoff.pas
===
--- compiler/ogcoff.pas (Revision 14564)
+++
Re: [fpc-devel] Adding a new assembler to Free Pascal Compiler
Hmm... one of the reasons why I might not have found this documentation is because of this: At the wiki/documentation link: Online documentation Remark:you must have javascript and style sheets enabled in order to view the html documentation correctly. The following documents are online available: (Followed by nothing) I guess either javascript or style sheets are disabled on my IE8 browser because of security risks :| Bye, Skybuck. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Recent changes to TField.SetData
Then please move approprate code at least into
TCustomBufDataset.SetFieldData
Thanks
This code was already there.
Should the 'Validate' code be moved there too ?
Yes. TDataset descendants are responsible to calling Validate, e.g.,
zeos call it inside TZAbstractRODataset.SetFieldData.
I agree, but I do not like idea, that SAME piece of code must be
repeated in many descendants of TDataSet (TCustomBufDataSet, TParadox,
TMemDataset, TFixedFormatDataSet, TDbf, TCustomSqliteDataset etc.)
So it would be good, if we can put 'validate code' into any new method?
and call it once from descendants (be precise only from descendants,
which are intended for use in FPC, because components which are also for
Delphi must do it in Delphi compatible way and can not use this new method)
One of the reasons of letting descendants call it it's too improve
granularity so Validate can be called in the middle of the routine, as
is in zeos, instead to force the call before the TDataset routine.
Yes, but I think, that in many cases can be expected, that 'validate'
will be called before any other action,
It seems, that TDataSet descendants never call inherited
TDataSet.SetFieldData(Field: TField; Buffer: Pointer);
(because it is empty method)
So if we move 'validate code' there then in 'our' descendants we put only
{$IFDEF FPC}
inherited;
{$ENDIF}
at first line. This does not affect existing tdataset descendants, and
FPC dataset descendants can be adjusted to benefit from this.
(I know, it is not perfect solution ;-) but I very dislike repeat same
'validate' code in X places)
--or--
introduce any new method (ValidateFieldData ? ;-))) and let tdatsset
descendants use it:
{$IFDEF FPC}
ValidateFieldData(Field: TField; Buffer: Pointer);
{$ENDIF}
--or--
some smarter solution ?
Laco.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
