MML's post on stable islands has made me think.

Below some ideas for discussion:
If we want to know whether a certain combination of OS+FPC+Lazarus+packages is stable, we:
1. should ask the user
2. don't trust him completely though and we should get measurements

Short-term action
=================
I suggest we can create a Lazarus GUI that
- asks the user how stable he thinks Lazarus is
- collects test measurement data (see below)
The GUI can then display the results, save them for the user's own use (import in database etc), and upload to a central web page

The GUI could run these tests:
- compiler test suite. Custom test code; results available as XML, IIRC.
- FPC database tests (e.g. for bufdataset, memds, sdfdataset, perhaps test Firebird embedded, sqlite, as well as any specified in the user's database.ini). These are fpcunit tests; can spit out e.g. XML
- any other fpc tests written with fpcunit
- Lazarus non-GUI tests (can't remember what data format these have)

Medium-term action
==================
- Have FPC report not only version but also SVN revision (much like lazarus does in help/about) so that data can be used to pinpoint exactly what version is used if checked out from SVN (e.g. trunk)
- Write small cross platform database application to collect, read in test results into database; useful for user's own use
- Similar but for a central web site. Web page with results could be done much like the compiler test suite page
- Extend FPC fpcunit tests for packages (both in coverage and number of packages tested)
- Extend Lazarus non-GUI tests (e.g. fill stringgrid, save as csv, load from csv, compare grid contents). Perhaps even a policy/behaviour change: no new units accepted without relevant tests (of course where feasible)
- Extend packages so that there is a self-test possibility: the GUI mentioned above) and/or IDE shoul run unit tests in the packages and get the resutls. Example: Lazreport creates sample report, outputs to file, and compares file contents with expected contents

Extending the test suites etc. would aid in regression testing as long as attention is paid to the trend in test faults.

What do you think?

Thanks,
Reinier

+1

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20120917/68b719c8/attachment.html>

2012/9/17 Reinier Olislagers :

MML's post on stable islands has made me think. - Have FPC report not only version but also SVN revision (much like lazarus does in help/about) so that data can be used to pinpoint exactly what version is used if checked out from SVN (e.g. trunk)

This is already available in the compiler, if you use fpc -iW.

You might not see it in the current installers, because they are built from svn exported directories, to increase stability in building.

Vincent

What is the use of displaying the svn revision if it doesn't work when building fpc from svn?

Ludo

2012/9/17 Ludo Brands :

None, that is why it is not shown now.

Vincent

With -iW I only get the fpc version, not the svn revision.

You might not see it in the current installers, because they are built from svn exported directories, to increase stability in building.

Mattias

2012/9/17 Mattias Gaertner :

With -iW I only get the fpc version, not the svn revision.

vincent at fpclin32:~/src/fpc/trunk$ compiler/ppc386 -iW 2.7.1-r1:22243

Vincent

$ ./compiler/ppcx64 -iW
2.7.1

Maybe it must be compiled with some special flag?

Mattias

Does that include untagged snapshots?

Are there cases where one or more files associated with a tagged version aren't in fact "locked down"? For example, if a file being worked on hasn't yet been committed to svn?

It is possible to look at either the files associated with a tagged version or the repository and to determine unambiguously what revision it was created at?

Mattias Gaertner wrote

With -iW I only get the fpc version, not the svn revision.

Same here, but I thought maybe it is because I use the git mirror, instead of SubVersion directly.

Regards,
- Graeme -

Vincent Snijders wrote

vincent at fpclin32:~/src/fpc/trunk$ compiler/ppc386 -iW 2.7.1-r1:22243

What does the 'r1' part mean? Surely not Revision 1?

Graeme.

I believe the colon indicates a range.

Actually, I'm failing to see the revision even with versions that I'm pretty sure I've built from svn:

0 2>markMLl at pye-dev-01:~$ ppcsparc-2.7.1 -iW
2.7.1

Mark Morgan Lloyd wrote

> vincent at fpclin32:~/src/fpc/trunk$ compiler/ppc386 -iW > 2.7.1-r1:22243 I believe the colon indicates a range.

Yes, I understand the colon syntax used by SubVersion, but why a range of 1?22243? This make no sense to me. So that's why I'm wonder what the 'r1' could really mean.

Regards,
- Graeme -

2012/9/17 Mattias Gaertner :

If the file compiler/revision.inc exists, it is updated during compilation with the output of "svnversion -c" and included in the compiler executable.

So before doing make all, do "touch revision.inc"

Vincent

On windows:

make clean all

Results in

version.pas(99,3) Error: Illegal expression
version.pas(103) Fatal: There were 1 errors compiling module, stopping Fatal: Compilation aborted
make[5]: *** [ppc386.exe] Error 1

revision.inc is empty.

Ludo

2012/9/17 Ludo Brands :

Results in

What is result of svnversion -c on your computer?

Ask on fpc-pascal or submit a fpc bug report.

Vincent

What is result of svnversion -c on your computer?

1:22412M

Will do,

Ludo