ichthyo/LUMIERA.clone
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
LUMIERA.clone/tests/library/diff/diff-list-application-test.cpp

121 lines
3.1 KiB
C++
Raw Normal View History

WIP: start with drafting the GUI diff representation ...first step is to design a generic linearised list diff representation. Basically just need to pull together the theoretical work of the last weeks. Next steps will be to extend to typed ordered trees.
2014-12-01 02:50:46 +01:00
/*
DiffListApplication(Test) - demonstrate linearised representation of list diffs
Copyright: clarify and simplify the file headers * Lumiera source code always was copyrighted by individual contributors * there is no entity "Lumiera.org" which holds any copyrights * Lumiera source code is provided under the GPL Version 2+ == Explanations == Lumiera as a whole is distributed under Copyleft, GNU General Public License Version 2 or above. For this to become legally effective, the ''File COPYING in the root directory is sufficient.'' The licensing header in each file is not strictly necessary, yet considered good practice; attaching a licence notice increases the likeliness that this information is retained in case someone extracts individual code files. However, it is not by the presence of some text, that legally binding licensing terms become effective; rather the fact matters that a given piece of code was provably copyrighted and published under a license. Even reformatting the code, renaming some variables or deleting parts of the code will not alter this legal situation, but rather creates a derivative work, which is likewise covered by the GPL! The most relevant information in the file header is the notice regarding the time of the first individual copyright claim. By virtue of this initial copyright, the first author is entitled to choose the terms of licensing. All further modifications are permitted and covered by the License. The specific wording or format of the copyright header is not legally relevant, as long as the intention to publish under the GPL remains clear. The extended wording was based on a recommendation by the FSF. It can be shortened, because the full terms of the license are provided alongside the distribution, in the file COPYING.
2024-11-17 23:42:55 +01:00
Copyright (C)
2014, Hermann Vosseler <Ichthyostega@web.de>
WIP: start with drafting the GUI diff representation ...first step is to design a generic linearised list diff representation. Basically just need to pull together the theoretical work of the last weeks. Next steps will be to extend to typed ordered trees.
2014-12-01 02:50:46 +01:00
Copyright: clarify and simplify the file headers * Lumiera source code always was copyrighted by individual contributors * there is no entity "Lumiera.org" which holds any copyrights * Lumiera source code is provided under the GPL Version 2+ == Explanations == Lumiera as a whole is distributed under Copyleft, GNU General Public License Version 2 or above. For this to become legally effective, the ''File COPYING in the root directory is sufficient.'' The licensing header in each file is not strictly necessary, yet considered good practice; attaching a licence notice increases the likeliness that this information is retained in case someone extracts individual code files. However, it is not by the presence of some text, that legally binding licensing terms become effective; rather the fact matters that a given piece of code was provably copyrighted and published under a license. Even reformatting the code, renaming some variables or deleting parts of the code will not alter this legal situation, but rather creates a derivative work, which is likewise covered by the GPL! The most relevant information in the file header is the notice regarding the time of the first individual copyright claim. By virtue of this initial copyright, the first author is entitled to choose the terms of licensing. All further modifications are permitted and covered by the License. The specific wording or format of the copyright header is not legally relevant, as long as the intention to publish under the GPL remains clear. The extended wording was based on a recommendation by the FSF. It can be shortened, because the full terms of the license are provided alongside the distribution, in the file COPYING.
2024-11-17 23:42:55 +01:00
  **Lumiera** is free software; you can redistribute it and/or modify it
  under the terms of the GNU General Public License as published by the
  Free Software Foundation; either version 2 of the License, or (at your
  option) any later version. See the file COPYING for further details.
WIP: start with drafting the GUI diff representation ...first step is to design a generic linearised list diff representation. Basically just need to pull together the theoretical work of the last weeks. Next steps will be to extend to typed ordered trees.
2014-12-01 02:50:46 +01:00
Copyright: clarify and simplify the file headers * Lumiera source code always was copyrighted by individual contributors * there is no entity "Lumiera.org" which holds any copyrights * Lumiera source code is provided under the GPL Version 2+ == Explanations == Lumiera as a whole is distributed under Copyleft, GNU General Public License Version 2 or above. For this to become legally effective, the ''File COPYING in the root directory is sufficient.'' The licensing header in each file is not strictly necessary, yet considered good practice; attaching a licence notice increases the likeliness that this information is retained in case someone extracts individual code files. However, it is not by the presence of some text, that legally binding licensing terms become effective; rather the fact matters that a given piece of code was provably copyrighted and published under a license. Even reformatting the code, renaming some variables or deleting parts of the code will not alter this legal situation, but rather creates a derivative work, which is likewise covered by the GPL! The most relevant information in the file header is the notice regarding the time of the first individual copyright claim. By virtue of this initial copyright, the first author is entitled to choose the terms of licensing. All further modifications are permitted and covered by the License. The specific wording or format of the copyright header is not legally relevant, as long as the intention to publish under the GPL remains clear. The extended wording was based on a recommendation by the FSF. It can be shortened, because the full terms of the license are provided alongside the distribution, in the file COPYING.
2024-11-17 23:42:55 +01:00
* *****************************************************************/
WIP: start with drafting the GUI diff representation ...first step is to design a generic linearised list diff representation. Basically just need to pull together the theoretical work of the last weeks. Next steps will be to extend to typed ordered trees.
2014-12-01 02:50:46 +01:00
Doxygen: prepare all unit tests for inclusion in the documentation Doxygen will only process files with a @file documentation comment. Up to now, none of our test code has such a comment, preventing the cross-links to unit tests from working. This is unfortunate, since unit tests, and even the code comments there, can be considered as the most useful form of technical documentation. Thus I'll start an initiative to fill in those missing comments automatically
2017-02-22 01:54:20 +01:00
/** @file diff-list-application-test.cpp
Doxygen: magically insert a reference to the test class this bit of Sed magic relies on the fact that we happen to write the almost correct class name of a test into the header comment. HOWTO: for F in $(find tests -type f \( -name '*.cpp' \) -exec egrep -q '§§TODO§§' {} \; -print); do sed -r -i -e' 2 {h;x;s/\s+(.+)\(Test\).*$/\\ref \1_test/;x}; /§§TODO§§/ {s/§§TODO§§//;G;s/\n//}' $F; done
2017-02-22 03:17:18 +01:00
** unit test \ref DiffListApplication_test
Doxygen: identify all files lacking a @file comment reason is, only files with a @file comment will be processed with further documentation commands. For this reason, our Doxygen documentation is lacking a lot of entries. HOWTO: find src -type f \( -name '*.cpp' -or -name '*.hpp' \) -not -exec egrep -q '\*.+@file' {} \; -print -exec sed -i -r -e'\_\*/_,$ { 1,+0 a\ \ \ /** @file §§§\ ** TODO §§§\ */ }' {} \;
2016-11-03 18:20:10 +01:00
*/
WIP: start with drafting the GUI diff representation ...first step is to design a generic linearised list diff representation. Basically just need to pull together the theoretical work of the last weeks. Next steps will be to extend to typed ordered trees.
2014-12-01 02:50:46 +01:00
#include "lib/test/run.hpp"
Diff Handling and Diff Application: framework and definitions factored out of the concept test built last week.
2014-12-15 03:21:19 +01:00
#include "lib/diff/list-diff-application.hpp"
experiment with how to represent a fixed inline diff sequence for the test ...also the first time to get this diff representation draft through the compiler TODO: implementation of the actual diff step application functions
2014-12-10 04:33:53 +01:00
#include "lib/iter-adapter-stl.hpp"
Diff Handling and Diff Application: framework and definitions factored out of the concept test built last week.
2014-12-15 03:21:19 +01:00
#include "lib/util.hpp"
WIP: start with drafting the GUI diff representation ...first step is to design a generic linearised list diff representation. Basically just need to pull together the theoretical work of the last weeks. Next steps will be to extend to typed ordered trees.
2014-12-01 02:50:46 +01:00
#include <string>
#include <vector>
Diff Handling and Diff Application: framework and definitions factored out of the concept test built last week.
2014-12-15 03:21:19 +01:00
using lib::iter_stl::snapshot;
WIP: start with drafting the GUI diff representation ...first step is to design a generic linearised list diff representation. Basically just need to pull together the theoretical work of the last weeks. Next steps will be to extend to typed ordered trees.
2014-12-01 02:50:46 +01:00
using util::isnil;
using std::string;
using std::vector;
namespace lib {
Diff Handling and Diff Application: framework and definitions factored out of the concept test built last week.
2014-12-15 03:21:19 +01:00
namespace diff{
WIP: start with drafting the GUI diff representation ...first step is to design a generic linearised list diff representation. Basically just need to pull together the theoretical work of the last weeks. Next steps will be to extend to typed ordered trees.
2014-12-01 02:50:46 +01:00
namespace test{
concrete implementation of diff application (finished concept draft) This implements the application of our new list diff language to a target sequence given within a vector. Unit test pass
2014-12-11 04:46:47 +01:00
reorganise the DSL aspect of the design we want a simple and straight forward way of defining tokens of the "diff language". Each token is bound to a specific handler function in the language interpreter interface.
2014-12-14 03:47:23 +01:00
namespace {//Test fixture....
WIP: start with drafting the GUI diff representation ...first step is to design a generic linearised list diff representation. Basically just need to pull together the theoretical work of the last weeks. Next steps will be to extend to typed ordered trees.
2014-12-01 02:50:46 +01:00
WIP: continued drafting of diff representation Basically attempt to represent the individual diff step as a tuple of "DiffVerb" and reference element. The meaning of the reference element depends on the actual verb
2014-12-04 04:41:07 +01:00
using DataSeq = vector<string>;
WIP: start with drafting the GUI diff representation ...first step is to design a generic linearised list diff representation. Basically just need to pull together the theoretical work of the last weeks. Next steps will be to extend to typed ordered trees.
2014-12-01 02:50:46 +01:00
#define TOK(id) id(STRINGIFY(id))
string TOK(a1), TOK(a2), TOK(a3), TOK(a4), TOK(a5);
string TOK(b1), TOK(b2), TOK(b3), TOK(b4);
experiment with how to represent a fixed inline diff sequence for the test ...also the first time to get this diff representation draft through the compiler TODO: implementation of the actual diff step application functions
2014-12-10 04:33:53 +01:00
reorganise the DSL aspect of the design we want a simple and straight forward way of defining tokens of the "diff language". Each token is bound to a specific handler function in the language interpreter interface.
2014-12-14 03:47:23 +01:00
using Interpreter = ListDiffInterpreter<string>;
using DiffStep = ListDiffLanguage<string>::DiffStep;
using DiffSeq = iter_stl::IterSnapshot<DiffStep>;
DiffStep_CTOR(ins);
DiffStep_CTOR(del);
DiffStep_CTOR(pick);
change list diff language to rely on 'find' instead of 'push' As decided in beb57cde this changeset switches our basic list diff language to work in the style of an insertion sort. Rather than 'pushing back' out-of-order elements, we scan and bring forward missing elements. Later, when passing the original location of the elements fetched this way, a 'skip' verb will help to clean up possible leftowers, so implementation is possible (and indeed acomplished) without shifting any other elements.
2015-01-02 13:18:25 +01:00
DiffStep_CTOR(find);
DiffStep_CTOR(skip);
reorganise the DSL aspect of the design we want a simple and straight forward way of defining tokens of the "diff language". Each token is bound to a specific handler function in the language interpreter interface.
2014-12-14 03:47:23 +01:00
inline DiffSeq
generateTestDiff()
{
return snapshot({del(a1)
, del(a2)
, ins(b1)
, pick(a3)
change list diff language to rely on 'find' instead of 'push' As decided in beb57cde this changeset switches our basic list diff language to work in the style of an insertion sort. Rather than 'pushing back' out-of-order elements, we scan and bring forward missing elements. Later, when passing the original location of the elements fetched this way, a 'skip' verb will help to clean up possible leftowers, so implementation is possible (and indeed acomplished) without shifting any other elements.
2015-01-02 13:18:25 +01:00
, find(a5)
reorganise the DSL aspect of the design we want a simple and straight forward way of defining tokens of the "diff language". Each token is bound to a specific handler function in the language interpreter interface.
2014-12-14 03:47:23 +01:00
, ins(b2)
, ins(b3)
, pick(a4)
change list diff language to rely on 'find' instead of 'push' As decided in beb57cde this changeset switches our basic list diff language to work in the style of an insertion sort. Rather than 'pushing back' out-of-order elements, we scan and bring forward missing elements. Later, when passing the original location of the elements fetched this way, a 'skip' verb will help to clean up possible leftowers, so implementation is possible (and indeed acomplished) without shifting any other elements.
2015-01-02 13:18:25 +01:00
, skip(a5)
reorganise the DSL aspect of the design we want a simple and straight forward way of defining tokens of the "diff language". Each token is bound to a specific handler function in the language interpreter interface.
2014-12-14 03:47:23 +01:00
, ins(b4)
});
}
}//(End)Test fixture
WIP: start with drafting the GUI diff representation ...first step is to design a generic linearised list diff representation. Basically just need to pull together the theoretical work of the last weeks. Next steps will be to extend to typed ordered trees.
2014-12-01 02:50:46 +01:00
/***********************************************************************//**
* @test Demonstration/Concept: a description language for list differences.
* The representation is given as a linearised sequence of verb tokens.
* This test demonstrates the application of such a diff representation
* to a given source list, transforming this list to hold the intended
* target list contents.
*
WIP start definition with a basic tree diff example...
2015-10-02 18:47:44 +02:00
* @see DiffListGeneration_test
* @see DiffTreeApplication_test
* @see VerbFunctionDispatch_test
WIP: start with drafting the GUI diff representation ...first step is to design a generic linearised list diff representation. Basically just need to pull together the theoretical work of the last weeks. Next steps will be to extend to typed ordered trees.
2014-12-01 02:50:46 +01:00
*/
class DiffListApplication_test : public Test
{
virtual void
run (Arg)
{
WIP: continued drafting of diff representation Basically attempt to represent the individual diff step as a tuple of "DiffVerb" and reference element. The meaning of the reference element depends on the actual verb
2014-12-04 04:41:07 +01:00
DataSeq src({a1,a2,a3,a4,a5});
settle architectural considerations regarding the TreeMuator concept so yes, it is complicated, and inevitably involves three layers of indirection. The alternative seems to bind the GUI direcly to the Session interface -- is there a middle gound? For the messages from GUI to Proc, we have our commands, based on PlacementRef entities. But for feeding model updates to the GUI, whatever I consider, I end up either with diff messages or an synchronised access to Session attributes, which ties the responsiveness of the GUI to the Builder operation.
2015-04-03 20:10:22 +02:00
DiffSeq diff = generateTestDiff();
WIP: start with drafting the GUI diff representation ...first step is to design a generic linearised list diff representation. Basically just need to pull together the theoretical work of the last weeks. Next steps will be to extend to typed ordered trees.
2014-12-01 02:50:46 +01:00
CHECK (!isnil (diff));
DataSeq target = src;
DiffApplicator<DataSeq> application(target);
application.consume(diff);
CHECK (isnil (diff));
CHECK (!isnil (target));
CHECK (src != target);
CHECK (target == DataSeq({b1,a3,a5,b2,b3,a4,b4}));
}
};
/** Register this test class... */
LAUNCHER (DiffListApplication_test, "unit common");
Diff Handling and Diff Application: framework and definitions factored out of the concept test built last week.
2014-12-15 03:21:19 +01:00
}}} // namespace lib::diff::test
Reference in a new issue Copy permalink