Your changes make good sense Klaus.
Of interest to me was that you made tag names safe against
white-space changes. Should this be a generic features of a parser to
do white-space reduction for those modes that could be affectedby
It would be nice if a Java guru could write a test.java file that
uses all the whacky java features that may be encountered. I will
contemplate a test.el. I usually use semanticdb.el or semantic.el as
a test candidate, but it makes sense to have a real candidate too.
>>> <klaus.berndl@...> seems to think that:
>Eric M. Ludlam wrote:
>>>>> <klaus.berndl@...> seems to think that: Hi,
>>> Eric M. Ludlam wrote:
>>>> There is certainly a discrepency between the doc and the
>>>> functionality. As you are the first to mention this eggregeous
>>>> error, perhaps these functions should just be deleted in favor of
>>>> direct calls to inversion..
>>> Yes, sounds senseful - so i have replaced semantic-required-version
>>> in my working-copy of semantic-regtest.el by a call to inversion...
>>> BTW: I took a look into PRERELEASE_CHECKLIST and found "use
>>> semantic-regtest.el". IMHO a good pointer... because i wrote this
>>> library more than 1 year ago i thought i it would maybe a good idea
>>> to test this stuff with current cedet ;-)=20
>>> First result: Fixing the inversion-stuff.
>>> But in general it works pretty smart (some selfpraising ;-)....
>>> So i would create for all test-files in semantic/test a
>>> reference-output with active cedet1.0beta3 and store them also in
>>> semantic/test... Then i will=20
>>> run a regression test with semantic-regtest-run-test for all
>>> test-files with active current CVS-cedet and check where are the
>>> differences... the output-=20
>>> files of these tests i will also store in semantic/test. This files
>>> are openend in a smart major-mode semantic-regtest-mode when
>>> semantic-regtest.el is loaded. So if there are parsing-differences
>>> betweeen current CVS and cedet1.0beta3 we can decide if they are ok
>>> and if yes, we make the regtest-outputs with CVS-cedet the new
>>> referencial-outputs so we get for future releases a good
>> That sounds useful. The reference output could be in semanticdb form,
>> but not necessarilly in a semanticdb.cache file. If you create
>> a file, you can use this:
>> (let ((obj semanticdb-current-table))
>> (set-buffer "reference-table")
>> (object-write semanticdb-current-table)))
>> to create the file. I think you can then use `eieio-persistent-read'
>> on the filename. I haven't tried it so who knows.
>IMO an output in the semanticdb-form is not a really good idea because
>this is a very propriate format (of course there is no real "standard"-
>format available but the semanticdb-format is far away from something
>like a generic format... ;-) I bet sometimes in the future (slightly)=20
>changing the semanticdb-format will be necessary and then we would throw
>away all out reference-regressiontest-results.
>I have added a patch to current semantic-regtest.el which produces a =
>generic tag-format and print this in the test-output-files (see for =
>the function semantic-regtest-convert-tag which is an overloadable =
>here are further design-guidelines of the current semantic-regtest.el:
>- Removed semantic 1.4 support: I did this because IMO all the current =
> 2.0-parsers are a) in detail more powerful than the semantic-1.4 =
> (some parsers like the java one are now much more powerful) and b) =
> enough and long enough in beta-use so we can give them the state: At =
> as good as the semantic 1.4 ones =3D=3D> conclusion: Supporting =
> by the regression-api is not worth the effort it costs (at least IMHO =
>- IMO very important is that regression-test-results are stable against
> whitespace-changes in the test-source-files because they do not =
> the parsing result and therefore the test-output must be robust =
> such source-changes...Therefore the regtest-lib converts all newlines
> in the tag-name (yes, tag-names can contain newlines and spaces i have
> learned after running regression-test against python-files ;-) and =
> to one single spaces and trimes all spaces-sequences also to exactly =
>- The whole test-output for one tag is written in exactly one line so
> line-oriented diff-tools like diff (and ediff which is used by the =
> can be used.
>- a comfortable and efficient way is needed to check and examine =
> between two test-runs (e.g. differences between the reference-output =
> the current test-output for a certain source-file). For this there is
> the new major-mode semantic-regtest-mode
>So if you don't have objections against the patch i will commit it into
>CVS and then produce the reference-test-outputs for the files in
>BTW: It would be good if youd also have a test.java, a makefile.test,
>a test.el (should contain eieio-classes too)... currently we seems to
>have a suitable test.cpp and a test.py...
>> [ ... ]
>>> BTW: In the past semantic-regtest.el was also mean to allow
>>> regression-tests between semantic-1.4-parsers and the
>>> semantic-2.X-parsers - therefore semantic-regtest itself is written
>>> with the semantic-1.4-API so it can run=20
>>> under semantic-1.4 too....
>>> Hmm, i currently mull over if it would make sense to port this lib
>>> to the semantic-2.0-API but then this lib can not run under
>>> semantic-1.4 and create test-output for semantic-1.4-parsers... But
>>> do we need this really? What do you think?
>> [ ... ]
>> It seems useful to test against 1.4 compatibility for 1.0.x releases,
>> and perhaps save it as semantic-regtest-1.4.el and provide an updated
>> one for later. I would like to someday obsolete the 1.4 API
>> sometime. It is very large.
>See above my points against the 1.4-port of the regtest-library.