[fpc-pascal] fpcUnit todo list
Dean, As requested. Here goes... Let me know what you think of Item 1? If you wanted to start with any of these, Item 1 would be good. :-) === Item 1 === I have an idea on improving the console runner output. Running the app as show below, it always defaults to xml output, which gives you a strange undesired result when combine with other parameters. What if we change the default output (when no --format has been specified) to just print a summary when the tests are complete. That way if specify the params '-a -p' we will get Example 1: ./fpcunitTextM2 -a -p Number of run tests: 20 Number of errors:0 Number of failures: 0 And if we specify the params '-a -p --file=results.xml' we will get Example 2: ./fpcunitTextM2 -a -p --file=results.xml Number of run tests: 20 Number of errors:0 Number of failures: 0 The default --format= was applied because the --file= triggered it. So xml output will appear in the results.xml file and the above output to the console window. And if we specify the params '-a -p --format=plain' we will get Example 3: ./fpcunitTextM2 -a -p --format=plain Test: TTestSlideParser.IsTest Test: TTestSlideParser.CreateSlide Test: TTestSlideParser.ReferenceNumber Number of run tests: 20 Number of errors:0 Number of failures: 0 ...because the --format was applied it overrides the -p parameter and just ouputs the --format specified to the console window. No '.' are printed between every 'Test:...' line. And if we specify the params '-a -p --format=plain --file=results.xml' we will get Example 4: ./fpcunitTextM2 -a -p --format=plain --file=results.xml Number of run tests: 20 Number of errors:0 Number of failures: 0 ...because the --file= was specified, the -p parameter is active again (unlike example 3) and outputs the progress and summary to the console and the test results to the results.xml file. And the last one, if we specify the params '-a' we will get Example 4: ./fpcunitTextM2 -a snip As normal. No '.' are printed, and the to default --format= output is applied and printed to the console window. Or should be instead only print the summary? -- Current undesired output --- ./fpcunitTextM2 -a -p ...snip --- END -- === Item 2 === DUnit interface compatability needs updating... I created a few more, just haven't submitted a patch yet. === Item 3 === In Windows using the GUI Test Runner. If you RMC (Right Mouse Click) in the treeview you get a error: List index (3) out of bounds. This does not occur in Linux. === Item 4 === Hierarchy view for test listing in XML. The XSLT file needs to be modified to support this. The XSLT files for Summary (used for emails) and Full (used for html pages) reporting needs to be submitted to SubVersion. I can't remember the others... the list is at home somewhere. Regards, - Graeme - ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] fpcUnit todo list
Graeme Geldenhuys schreef: Dean, As requested. Here goes... Let me know what you think of Item 1? If you wanted to start with any of these, Item 1 would be good. :-) === Item 1 === I have an idea on improving the console runner output. Running the app as show below, it always defaults to xml output, which gives you a strange undesired result when combine with other parameters. What if we change the default output (when no --format has been specified) to just print a summary when the tests are complete. That way if specify the params '-a -p' we will get Example 1: ./fpcunitTextM2 -a -p Number of run tests: 20 Number of errors:0 Number of failures: 0 IMHO the 'Number of ...' should be enabled with a new -s (and --summary) switch === Item 4 === Hierarchy view for test listing in XML. The XSLT file needs to be modified to support this. The XSLT files for Summary (used for emails) and Full (used for html pages) reporting needs to be submitted to SubVersion. First the XML needs to change and then the XSLT files can be adapted, correct? Vincent ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] fpcUnit todo list
On 09/11/06, Vincent Snijders <[EMAIL PROTECTED]> wrote: > Number of run tests: 20 > Number of errors:0 > Number of failures: 0 IMHO the 'Number of ...' should be enabled with a new -s (and --summary) switch That makes sence, yes. > Hierarchy view for test listing in XML. The XSLT file needs to be > modified to support this. The XSLT files for Summary (used for > emails) and Full (used for html pages) reporting needs to be submitted > to SubVersion. First the XML needs to change and then the XSLT files can be adapted, correct? Yes, the XML will change, then the XSLT adapted. Regards, - Graeme - ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] 0.9.20 released
Hello,
I did a plain install from scratch (the
Lazarus-0.9.20-fpc-2.0.4-20061105-win32.exe) and wanted to rebuild
Lazarus. The rebuild with the preinstalled fpc-2.0.4 stops with an error:
Compiling svn2revisioninc.pas
Linking .\svn2revisioninc.exe
.\svn2revisioninc.o(.data+0x14): In function `FINDREVISION':
svn2revisioninc.pas:150: undefined reference to `DEBUGINFO_WINDOWS'
C:\lazarus.0.9.20\fpc\2.0.4\units\i386-win32\rtl\libpsystem.a(system0s884.o)(.text+0x68):
In function `SYSTEM_init':
system.pp:1133: undefined reference to `_stkptr'
Error: Error while linking
Next problem:
Because I prefer the fpc2.1.1 compiler i changed the setup to use my
fpc-2.1.1. (current svn snapshot). I did a "make clean all" Everything
builds well, but when i try to start lazarus it throws an exception:
Error reading SplashForm.Left. Unknown property "Left"
The same errror is thrown, when you install the
Lazarus-0.9.21-fpc-2.1.1-20061108-win32.exe and start lazarus.
Seems like the 2.1.1 compiler has problems with RTTI.
I know, the daily snapshots are not tested, but i think its nice to use
lazarus, with the 2.1.1 compiler.
cheers,
Adrian.
Mattias Gaertner schrieb:
The Lazarus team is glad to announce the 0.9.20 release. This release
is based on fpc 2.0.4.
This release can be downloaded from the sourceforge download page:
http://sourceforge.net/project/showfiles.php?group_id=89339
Detailed list of changes:
New widgetset: fpgui
updated translations: german, finnish, catalan, russian,
italian, africaans (af-za), spanish
IDE: renaming a component now automatically renames methods
with default names, and inherited components
made TColorButton a TCustomSpeedButton descendant
from Tom Gregorovic
Capture any mouse button by setting TControl.CaptureMouseButton
property from Tom Gregorovic (#7653)
LCL: published TAction.DisableIfNoHandler
LCL: setup better default properties for png writer
from Tom Gregorovic
IDE: project directory is now added to the include path
of all project directories
sqldb package: added TOracleConnection to component palette
win32 installer: fixed including the binutils from fpcbuild
creating package makefiles: the win64 OS uses the win32 widget set
svn2revisioninc can parse svn 1.4 meta data to determine a version
debugger: added dwarfloading to windebugger
added exception dissection
added linenumber address resolving
added setting of breakpoints
the search results window now has a close button for non gtk users
trayiconlaz: moved TTrayIcon to 'additional' tab in component
palette for Delphi compatibility
LCL: added TStaticText to 'additional' tab in component palette
for Delphi compatibility
IDEIntf: image list editor: implemented auto splitting
of added image from Etrusco
synedit: codefolding is now completely implemented and
enabled as default in the IDE. It uses simple begin..end blocks
as demonstration. Eventually nicer block boundaries will be used.
grids, picklist select fixed
TrimFilename no longer reduces ${Macro}/.. directories
cups printing: implemented default paper sizes from Jesus
moved code from TControlScrollBar to TScrollingWinControl,
deriving TScrollingWinControl from TCustomControl from Flavio
added example to add IDE help for the sources of a package
examples/helpforpackage/demopackagewithhelp.lpk
test runner: added writing results to file
and showing simple progress
fpcunit: new console runner uses new fpcunitconsolerunner package
qt intf:
Patch from zeljko. Implements TQtAbstractSlider, TQtScrollBar,
TQtTrackBar, TQtPen (CreatePenIndirect)
and TQtRegion (CreateRectRgn).
Unified qt4 header files. Updated bindings to 1.21
added support for menus, font, progressbar and statusbar
Combobox
And two hundred fixes and minor improvements.
Mattias
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] 0.9.20 released
Adrian Veith schreef: Hello, Next problem: Because I prefer the fpc2.1.1 compiler i changed the setup to use my fpc-2.1.1. (current svn snapshot). I did a "make clean all" Everything builds well, but when i try to start lazarus it throws an exception: Error reading SplashForm.Left. Unknown property "Left" The same errror is thrown, when you install the Lazarus-0.9.21-fpc-2.1.1-20061108-win32.exe and start lazarus. Seems like the 2.1.1 compiler has problems with RTTI. I know, the daily snapshots are not tested, but i think its nice to use lazarus, with the 2.1.1 compiler. This is a known issue with the fpc 2.1.1 compiler. Vincent ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] fpcUnit todo list
First, I would prefer a patch to the fpcunit which makes the unit itself indenpendend from other stuff (xml) so it can be used in the fpc test suite :) ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] fpcUnit todo list
On 09/11/06, Florian Klaempfl <[EMAIL PROTECTED]> wrote: First, I would prefer a patch to the fpcunit which makes the unit itself indenpendend from other stuff (xml) so it can be used in the fpc test suite :) The xml used is the xmlwriter unit - part of FPC. Is this a problem? Test output is optional, so you can chose no output, plain text output, xml output, latex output (not sure if this works) and all the previous to a file. The fpcunit.pp doesn't contain any reference to the testreport.pp unit... Maybe if you could explain 'independant' a bit better, I would get a better understanding of you requirement. We could change the output formats to register with fpcUnit, by creating a OutputFactory, and as soon as any output format unit is included (in uses clause) in a project (as in GUI Runner or Console Runner), it registers with the OutputFactory. I use this a lot in my projects and in tiOPF. Examples of this is different compression algorithms used by a tiCompress class used in tiOPF. Regards, - Graeme - ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] fpcUnit todo list
On Thu, 9 Nov 2006, Florian Klaempfl wrote: > First, I would prefer a patch to the fpcunit which makes the unit itself > indenpendend from other stuff (xml) so it can be used in the fpc test suite :) The unit fpcunit is independent of XML ? The package as a whole is dependent on XML, this is correct. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] fpcUnit todo list
On 9 nov 2006, at 11:47, Graeme Geldenhuys wrote: On 09/11/06, Florian Klaempfl <[EMAIL PROTECTED]> wrote: First, I would prefer a patch to the fpcunit which makes the unit itself indenpendend from other stuff (xml) so it can be used in the fpc test suite :) The xml used is the xmlwriter unit - part of FPC. Is this a problem? The problem is that the xml stuff must be built before you can run the testsuite with fpcunit tests included (since the fpcunit package depends on the xml stuff). This means that before you can start running the testsuite, your compiler has to be stable and complete enough to compile packages and fcl. That's not reasonable. Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] fpcUnit todo list
On 09/11/06, Jonas Maebe <[EMAIL PROTECTED]> wrote: > The xml used is the xmlwriter unit - part of FPC. Is this a problem? The problem is that the xml stuff must be built before you can run the testsuite with fpcunit tests included (since the fpcunit package depends on the xml stuff). This means that before you can start running the testsuite, your compiler has to be stable and complete enough to compile packages and fcl. That's not reasonable. Ok, so if the OutputFactory idea is also not going to work. Why not try something completely different. What if every test suite compiled to a .dll or .so file - nothing more. The fpcUnit executable compiled previously with a stable compiler and includes all the output format are then run during the nightly builds. The fpcUnit executable can parse and load the .dll or .so test suites and execute them (run their contained test cases). The nightly compiler run then only needs to compile the test suites to .dll or .so files. Well something like that anyway... :-) Would something like this be possible? Regards, - Graeme - ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] fpcUnit todo list
On 9 nov 2006, at 12:49, Graeme Geldenhuys wrote: Ok, so if the OutputFactory idea is also not going to work. Why not try something completely different. What if every test suite compiled to a .dll or .so file - nothing more. The fpcUnit executable compiled previously with a stable compiler and includes all the output format are then run during the nightly builds. There may not be a previous stable compiler (there isn't when you just start porting). Also, the target may be an embedded platform without any dynamic library loading capability. Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] fpcUnit todo list
On Thu, 9 Nov 2006, Jonas Maebe wrote: > > On 9 nov 2006, at 11:47, Graeme Geldenhuys wrote: > > >On 09/11/06, Florian Klaempfl <[EMAIL PROTECTED]> wrote: > > >First, I would prefer a patch to the fpcunit which makes the unit itself > > >indenpendend from other stuff (xml) so it can be used in the fpc test suite > > >:) > > > >The xml used is the xmlwriter unit - part of FPC. Is this a problem? > > The problem is that the xml stuff must be built before you can run the > testsuite with fpcunit tests included (since the fpcunit package depends on > the xml stuff). This means that before you can start running the testsuite, > your compiler has to be stable and complete enough to compile packages and > fcl. That's not reasonable. The easiest thing to do is to include fpcunit itself in fcl/inc. All the units around it can be done in fcl/fpcunit, which is built at a later stage. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] fpcUnit todo list
>> On 09/11/06, Florian Klaempfl <[EMAIL PROTECTED]> wrote: >>> First, I would prefer a patch to the fpcunit which makes the unit >>> itself >>> indenpendend from other stuff (xml) so it can be used in the fpc >>> test suite :) >> >> The xml used is the xmlwriter unit - part of FPC. Is this a problem? > > The problem is that the xml stuff must be built before you can run > the testsuite with fpcunit tests included (since the fpcunit package > depends on the xml stuff). This means that before you can start > running the testsuite, your compiler has to be stable and complete > enough to compile packages and fcl. That's not reasonable. Wait a minute But you need a stable enough compiler to compile the testsuite right? Hmm either you're inconsistent or you plan to test only the RTL and compiler itself, am I right? Darius ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] fpcUnit todo list
On 09/11/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: Wait a minute But you need a stable enough compiler to compile the testsuite right? That's what I wast trying to get at... You need a compiler already. As to the order of how things are compiler and tested (RTL, FCL, etc) I have no idea how that currently works. Graeme. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] fpcUnit todo list
On Thu, 9 Nov 2006, [EMAIL PROTECTED] wrote: > >> On 09/11/06, Florian Klaempfl <[EMAIL PROTECTED]> wrote: > >>> First, I would prefer a patch to the fpcunit which makes the unit > >>> itself > >>> indenpendend from other stuff (xml) so it can be used in the fpc > >>> test suite :) > >> > >> The xml used is the xmlwriter unit - part of FPC. Is this a problem? > > > > The problem is that the xml stuff must be built before you can run > > the testsuite with fpcunit tests included (since the fpcunit package > > depends on the xml stuff). This means that before you can start > > running the testsuite, your compiler has to be stable and complete > > enough to compile packages and fcl. That's not reasonable. > > Wait a minute But you need a stable enough compiler to compile the > testsuite right? Hmm either you're inconsistent or you plan to test only > the RTL and compiler itself, am I right? That is what the current testsuite does: test the compiler and (parts of) RTL. But if the compiler has problems compiling classes and/or handling exceptions, you can forget the whole fpcunit anyway. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] fpcUnit todo list
On 9 nov 2006, at 13:33, [EMAIL PROTECTED] wrote: Wait a minute But you need a stable enough compiler to compile the testsuite right? You need a lot more compiler functionality to compile the fcl than to compile individual tests (not to mention that a problem which occurs when compiling a small test is much easier to debug than one which occurs when compiling a large fcl or packages unit). Hmm either you're inconsistent or you plan to test only the RTL and compiler itself, am I right? Initially (or when things are really messed up), that's the case yes. Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Fwd: [fpc-pascal] fpcUnit todo list
Begin forwarded message: From: Dean Zobec <[EMAIL PROTECTED]> Date: 9 november 2006 19:45:56 GMT+01:00 To: Florian Klaempfl <[EMAIL PROTECTED]>, Michael Van Canneyt <[EMAIL PROTECTED]> Cc: Graeme Geldenhuys <[EMAIL PROTECTED]>, [EMAIL PROTECTED] Subject: Re: [fpc-pascal] fpcUnit todo list I'm unable to post in the mailing list this evening, I constantly get an error, so I'm sending you a private mail. Excuse me for this. Florian Klaempfl wrote: First, I would prefer a patch to the fpcunit which makes the unit itself indenpendend from other stuff (xml) so it can be used in the fpc test suite :) This is my opinion too. fpcunit.pp is independent from xml, you can build a simple runner for the tests that does not rely on other stuff. But fpcunit.pp depends on classes and sysutils, the whole framework is built on exceptions and classes, and these are not available in early ports to new platforms. So fpcunit cannot be used as a regression testsuite for the compiler and low level rtl stuff. Btw, the fpc testsuite is very advanced in it's simplicity and low dependencies and it's probably the main thing that made fpc great. The first thing that made me to begin using fpc (well before I started working on fpcunit) was the existence of the testsuite covering all aspects of the compiler. I trust fpc more than Delphi because of this :) Of course to test the fcl and maybe some high level rtl classes fpcunit is very handy, it simplifies even more the writing of powerful tests for the fcl classes, some are using it as a Test Driven Development tool, others may need it to refactor existing fcl classes, some would use it as simple regression tests, some even for functional (acceptance) tests (Vincent has a lot of fantasy for finding new uses for it, e.g. he uses it to assure that the Lazarus examples compile :) . So I agree with Florian and Michael, I would like to integrate as much as possible fpcunit in the existing fpc testsuite environment in addition to the existing fpc testsuite. In my opinion it's a pity that the fpcunit tests built by the programmers that use it to test some new fcl classes are sitting on the programmer's computer instead of being part of the fpc official testsuite and run each night against the problems that may arise with changes applied each day to the fcl. If output format of the results is a concern for some programmers my best bet would be to use simple latex as a reporting tool, so the results can be easily converted in pdf and html (much more powerful imo then xml), thus avoiding any dependency on xml in the test runner. The easiest thing to do is to include fpcunit itself in fcl/inc. All the units around it can be done in fcl/fpcunit, which is built at a later stage. Michael. I agree with this. Dean ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: Fwd: [fpc-pascal] fpcUnit todo list
Jonas Maebe schrieb: The easiest thing to do is to include fpcunit itself in fcl/inc. All the units around it can be done in fcl/fpcunit, which is built at a later stage. Michael. I agree with this. This arises a fundamental question: should the tests for all package (non rtl/compiler!) go into fpc/tests/ or should they be in fpc//test and being executed by make tests in fpc/? At least it should be possible to run the package specific tests without running the whole testsuite. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: Fwd: [fpc-pascal] fpcUnit todo list
On Thu, 9 Nov 2006, Florian Klaempfl wrote: > Jonas Maebe schrieb: > > > > The easiest thing to do is to include fpcunit itself in fcl/inc. > > > > > > > All the units around it can be done in fcl/fpcunit, which is built at > > > > a later stage. > > > > > > > > Michael. > > > I agree with this. > > This arises a fundamental question: should the tests for all package (non > rtl/compiler!) go into fpc/tests/ or should they be in > fpc//test and being executed by make tests in fpc/? At least it It must be fpc/package/tests. Peter and I decided to build support in the packager for this, so you can - download - compile - test - install a package... Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Fwd: [fpc-pascal] fpcUnit todo list
Begin forwarded message: From: Dean Zobec <[EMAIL PROTECTED]> Date: Fri 10 Nov 2006 00:04:44 GMT+01:00 To: Florian Klaempfl <[EMAIL PROTECTED]>, Michael Van Canneyt <[EMAIL PROTECTED]>, Jonas Maebe <[EMAIL PROTECTED]> Subject: Re: Fwd: [fpc-pascal] fpcUnit todo list Michael Van Canneyt ha scritto: On Thu, 9 Nov 2006, Florian Klaempfl wrote: Jonas Maebe schrieb: The easiest thing to do is to include fpcunit itself in fcl/inc. All the units around it can be done in fcl/fpcunit, which is built at a later stage. Michael. I agree with this. This arises a fundamental question: should the tests for all package (non rtl/compiler!) go into fpc/tests/ or should they be in fpc//test and being executed by make tests in fpc/? At least it It must be fpc/package/tests. Peter and I decided to build support in the packager for this, so you can - download - compile - test - install a package... Michael. Good idea ! :) I agree, the first thought I had was to put them in fpc//tests directory, they should be somehow close to the production code. The support in the packager is absolutely great! But it would be also useful that the main build process would be able to build all the tests in a single runner program and run them at once. I think that even with a very large number of tests the suite of all unit tests could be built and run in less than a minute considering that is a single program (of course a configuration file could be added to be able to skip some tests that take more time to run). Dean P.s Michael, did you receive my mail with the attached packages tests you've asked for? ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Initializing record variables
Hi,
I have to translate a lot of assignements like this:
particle_t = record
name: array [0..Pred(16)] of char;
longi: integer;
pressure: float;
temperature: double;
lati: integer;
end;
ibuf: array [0..Pred(2)] of particle_t;
(* raw translation by automatic tool *)
ibuf:=(('zero'#0,0,0.0f,0.0,0),('zero'#0,0,0.0f,0.0,0));
from C to pascal. To make it easier I'd like to write something like:
ibuf: array [0..Pred(2)] of particle_t = ???
analoguous to
i: integer = 42;
Is there any syntax allowing to do so? If yes, it would be very easy to
do instead of addressing each record field by name for any record in the
target array.
TIA,
Marc
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Initializing record variables
> particle_t = record
> name: array [0..Pred(16)] of char;
> longi: integer;
> pressure: float;
> temperature: double;
> lati: integer;
> end;
>
> ibuf: array [0..Pred(2)] of particle_t;
> (* raw translation by automatic tool *)
> ibuf:=(('zero'#0,0,0.0f,0.0,0),('zero'#0,0,0.0f,0.0,0));
This should work:
type
TRoleDetails = record
Name, Descr: String;
end;
const
cRoles: array[1..3] of TRoleDetails = (
(Name: 'zEditRole'; Descr: 'z Edit role descr'),
(Name: 'yEditRole'; Descr: 'y Edit role descr'),
(Name: 'xEditRole'; Descr: 'x Edit role descr')
);
You need to name the elements, and they need to be in the order they're
declared in the record.
Moz
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
