Code testing proposal about cp-algorithms HOT 16 CLOSED

@RodionGork Acctually I did understand you. What I meant with "copy and paste" you called "propagate automatically". Of course I don't want to have the code duplicated in the repo, I also want it to be copied either in the convert process or in the testing process.

To make it more clear: I would prefer this option.
The md files contain code snippets (but only the important code, not the testing code).
The testing script will extract all the code snippets, and patched the test files.

E.g. one idea would be the following:

<Fibonacci.md>
Yada, yada, yada, ...
You can compute the Fibonacci numbers like this:
```cpp fibonacci_snippet
int fib(int n) { return n <= 1 ? 1 : fib(n - 1) + fib(n - 2); }
```

A script, which runs right at the beginning of testing, extracts all snippets into .h files. So this gives:

<fibonacci_snippet.h>
int fib(int n) { return n <= 1 ? 1 : fib(n - 1) + fib(n - 2); }

And the test file could look like this:

<test_fibonacci.cpp>
#include <assert.h>
#include "fibonacci_snippet.h"
int main() {
    assert(fib(2) == 2);
}

This way we actually don't need to modify (paste the snippets) the test files at all, only extract them into header files. #include does the pasting.

from cp-algorithms.

The idea seems to be great, however I'm not sure the html comments is the most convenient place to store these tests... Some pages are already large enough...

Probably it would be ok instead to create separate files with detailed code and tests. They could be referenced in the article, below the snippet of code, like "see details"... Though probably this is not very handy too?

P.S. Idea about travis/ci is wonderful (though I'm unacquainted with it - first heard of it couple of months ago).

from cp-algorithms.

Yeah, I don't like having the code in a separate file.
Because then the code appears twice. And we don't test the code in the .md files, which I think should be the priority.

from cp-algorithms.

I see, thanks for explanation!

But what if we have code in separate files, and in md files only special tags to include this code automatically, so it is not duplicated?

This could be done either when constructing html from md, or when the page is already loaded with javascript. This may help showing either some important part of code, or whole file (with special button?)

from cp-algorithms.

@jakobkogler after thinking a bit and playing a bit with travis-ci I believe I'm ready to agree with your approach and try to participate.

However, what do you think - could we at least put test in separate file? E.g. file which contains main and testcases, but requires that snippet (which is being tested) be extracted from the specific MD file and injected into this code file. This will allow us having more freedom about what to write in the test code, and reduce what is needed to be copy-pasted between code file and MD.

from cp-algorithms.

@RodionGork Yes, this will also be fine.
It is of course also not ideal, since suddenly the code is split into multiple places, but I doubt that there is a really beautiful solution. My approach is also not especially good, for the reasons you mentioned earlier.

Somehow we need a method to give snippets a name, so that we can refer to them in the cpp test files.
Maybe `` `cpp snippet1?

from cp-algorithms.

@jakobkogler thanks for the answer!

There is a way to keep the code in a single file - namely, if we will not fetch code from MDs to CPPs, but on contrary, keep it (necessary snippets marked) in CPPs and then injected where required in MDs.

So that CPP file has marks like:

//#snippet1
int myfunc(int x) { return x*x;}
//#snippet1-end
void main() { ... }

and markdown will have no code, just references something like

<!--?source somefile.cpp#snippet1-->

But I'm not sure, will you like this idea or not... It is technically different (and perhaps not to the best), but this of course remove any necessity for copy-paste activities (which I suspect may lead to minor errors sometimes).

from cp-algorithms.

@RodionGork I think having the code directly in the md files is better.
Then at least all the parts that are shown on a page are in one single file. Which also makes editing the files online (via test.php) easier (I'm pretty sure that I'm the only one editing/reviewing/translating articles from the terminal instead of the browser).

Copy and paste will be there in either way. If you put the snippets directly in the cpp files, you will have to copy-paste them into the md files.

from cp-algorithms.

@jakobkogler sorry, it seems I couldn't make my idea clear enough:

If you put the snippets directly in the cpp files, you will have to copy-paste them into the md files.

No. That is what I want to avoid. I think we can work so that code is propagated automatically to resulting HTML files when rendering MDs with references to it. So MDs won't have code inside at all. Though I'm not sure if it will be more convenient or less.

The matter is that some articles are large enough, and have several code snippets inside:

https://e-maxx-eng.appspot.com/data_structures/segment_tree.html

And I feel it would not make beautiful source with several (or single large) testing snippets inside. Which may hinder people from participating in improving such articles later...

from cp-algorithms.

@jakobkogler ah, ok, let's follow this way if you prefer :)

I'm not quite sure why you don't like the idea of propagating code into md files, but I don't like it myself because it is technically awkward.

Your approach looks fine to me, except that:

• the code in H files (horror, horror) :)
• editing working code is just a bit more tricky as it is not in code file, but in markdown
• not all languages have includes (but 99.9% of our code is in CPP anyway)

But there is great advantage on the other hand, in what you propose here - namely that markdown files remain virtually untouched and unchanged, and almost care nothing of whether there are tests or no. I believe this outweighs any of my minor complaints :)

So we can proceed with this approach and... what do we need by the way to proceed? Have you enough rights to setup travis with these repos when you want?

from cp-algorithms.

@RodionGork

• What's wrong with .h files?
  As far as I understand C++, the compiler just pastes the content of x.h into the cpp file at the location of #include "x.h". So this should work for functions, but as well as for really small snippets like variable definitions.
  Another nice thing about .h files is, that this automatically gives support for IDEs. I.e. first you run the script to extract all snippets locally, and then you can start writing the tests with autocompletion, error messages, ..., because any IDE understands how to handle includes. Whereas any custom syntax will break IDEs.

• Yes, it is more annoying to write code in markdown files, but I don't think this will be too bad. Also we already do this right now!

• I would suggest to actually remove all non C++ code. grep mentions only 3 instances of Python code, and only 2 instances of Java code. Most of them already contain duplicated code (i.e. equivalent C++ code is also available). I don't think it is necessary provide implementations in multiple languages, and we can remove / rewrite the few code snippets in different languages.

• Yes, this is also why I prefer tests this way. The markdown files contain exactly what you see on the website. Nothing more, nothing less.

• Yes, I have the necessary rights to setup Travis CI.

• From you I only need support for naming code snippets in markdown files. If we use the notation <backtick><backtick><backtick>cpp snippet_name, this should be easily done via a regex substitution. E.g. like this: example substitution.
  Tool for extracting the snippets, and running the test I can write myself.

from cp-algorithms.

Btw, just a quick question.
Is it possible to run the php converter local, without setting up a server?
E.g. by running php serve.php algebra/phi-function.html

from cp-algorithms.

Aha, thanks for guidance. I was ignorant enough to think that this snippets naming is existing markdown feature :) I've added it with regexp, as you proposed! Please see, if it works as intended.

About converting files locally. This is how e-maxx-eng worked before switching to appengine in late 2016 - so now we happily got rid of this functionality :)

It is not that hard to add some code to allow it work, but the serious problem is that, I suppose, generated HTMLs won't look nicely in the browser if you load them from local filesystem (e.g. with file:///home/my/algebra/phi-function.html - all the javascript which is fetched from the web (first and most important - LaTeX convertor) will be disabled, I suspect.

If this would be a helpful feature, we can rather add some script which helps with running small local server instead. E.g. I believe this could be a single python script using BaseHTTPServer and relying on live server for conversion itself, so no php installation is needed... (another option is to use full GAE dev kit, but this probably is not the what we need as by default code will fetch markdown sources from github, rather than local disk)

About removing non-cpp snippets. I'm ok with that. I'm not a big fan of cpp, so I think I've added at least one of the mentioned python snippets. But as it seems people in competitive programming still like cpp more than anything, let it be :)

As about supporting more than 1 language, it is a more political/SEO question. If this site is targeted strictly to CP-people, then CPP seems to be ok. However we definitely lose a part of audience who, like college students, may google these articles for their study/scientific purpose. They will rarely be glad for CPP code. However I don't think we currently have resources to provide ports in Java/Python anyway. Unless we call for community to participate in this specific task. But then we surely couldn't conveniently paste snippets in many languages in the articles (at least without using "show/hide" buttons - don't remember whether they still work)... :)

from cp-algorithms.

@RodionGork
I tried the new plan: https://github.com/jakobkogler/e-maxx-eng/commits/travisci_tests
The second last commit shows the implementation. A Python script iterates over all .md files and extracts all named snippets into .h files. And a shell script compiles and runs all .cpp files in the test folder. If the compilation/running failed, then the script will tell Travis by returning 1.
And the last commit is an example test for the Sparse Table article.
The results on Travis CI can be found here: https://travis-ci.org/jakobkogler/e-maxx-eng

The .cpp files that test the snippets are still a little undefined.
I'm not quite sure if we should use a test framework, create some test macros on our own, or just use assert, like I did it the example test.

Also currently it extracts all names snippets, which might give name collapses if two snippets in different files have the same name. Maybe it would be better to extract the snippets for one file, compile and run the tests for this file, remove .h files, and then repeat the process for all other files.

I will think about it a little bit more, and only then merge the commits.

from cp-algorithms.

I will think about it a little bit more, and only then merge the commits.

Honestly, I do not think it is necessary - such experiments and improvements may take place at the repo all right, as they are not going to break the page rendering etc... (yes, except my bug with spaces which you kindly fixed) - so feel free!

from cp-algorithms.

I merged the tests.
And also added some short informations about writing tests in contrib.md.

from cp-algorithms.