<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">2013/8/8 Christoph Grüninger <span dir="ltr"><<a href="mailto:christoph.grueninger@iws.uni-stuttgart.de" target="_blank">christoph.grueninger@iws.uni-stuttgart.de</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Miha,<br>
please keep in mind that we prefer to communicate over our devel<br>
mailinglist. This way every interested developer can keep track<br>
of your progress. If you think that a message is better to<br>
be sent in private, you must not forget to add both Christian<br>
and me.<br></blockquote><div>I'll blame this one on GMail, I used to have it setup to automatically "reply to all" when I click reply. Apparently they reset it.  <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<br>
Make the change to Doxygen and CMake if you like. But hurry up,<br>
there is no time to waste. Ask early because I am only available<br>
until Friday. In general, I think we should gain momentum and<br>
speed up again.<br></blockquote><div>I added CMake support (wasn't much to do), and partly switched to Doxygen. <br></div><div>Note that the documentation itself isn't changed yet, only Doxygen is called on it. <br>
</div><div>Before you go, could you just try to run it and tell me if I missed anything?<br></div><div>Both with cmake and autotools configuration. <br><br></div><div>If the build-system works, I think I can add some statistics and then start working on the website. <br>
</div><div>I'm a bit more confident there, at least for getting started. <br></div><div>A website would share a lot of the front-end code with the local generation anyway. <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<br>
Would you mind to update the time table you gave in your application?<br>
It describes what you wanted to achieve for every week. That's a<br>
handy way to track progress and see what we can expect. And it reveals<br>
delays what becomes more important towards the end.<br></blockquote><div>I don't think I can (or should) change the application itself. <br></div><div>But I will post a comparison of the original plan and the current results here if you wish.  <br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I am not sure about how to get the information about git revision and<br>
the compiler command. But you can try to capture the output from<br>
some git command and the first lines of make. That would include all<br>
the necessary information.<br></blockquote><div>You may have noticed I added reading from some .ini files, which tell us what to do and what to measure. <br></div><div>Getting revision is easy, for example git has "git rev-parse HEAD", and it should be similar for most other VCS's. I'm not sure about getting the compiler and its flags automatically,  though. <br>
</div><div>I'll see what I can do. <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Bye<br>
Christoph<br>
<br>
Miha Čančula <<a href="mailto:miha@noughmad.eu">miha@noughmad.eu</a>> schrieb:<br>
> 2013/8/5 Christoph Grüninger <<a href="mailto:christoph.grueninger@iws.uni-stuttgart.de">christoph.grueninger@iws.uni-stuttgart.de</a>><br>
><br>
> > Hi Miha,<br>
> > if you have no strong feelings about Sphinx versus Doxygen I'd ask you<br>
> > to change for the latter; but the change has low priority.<br>
> ><br>
> With things like that, I have a feeling that if it's not done immediately<br>
> it may never get done.<br>
> I should probably convert to Doxygen before writing any more docs.<br>
> I won't take much time anyway.<br>
><br>
> ><br>
> > > Yes, I agree. I must confess I'm still not entirely familiar with<br>
> > > autotools,<br>
> > > so I didn't make it optional yet, but it's definitely on my to-do list.<br>
> ><br>
> > I know, autotools can be hard to begin with. If you have questions,<br>
> > don't hesitate to ask us. Currently Doxygen is optional. The class<br>
> > documentation is only built for systems with Doxygen installed. But<br>
> > this is not an issue after the change.<br>
> ><br>
> > [CMake]<br>
> > > No, it's because I haven't included the CMake files yet.<br>
> ><br>
> > I just saw that you committed a CMakeLists.txt file but I did not<br>
> > check that.<br>
> > You don't have to include CMake support. You are right, we are<br>
> > evaluating the pros and cons for a switch or for keeping both. If<br>
> > you want, you can share your opinion, too.<br>
> > You can add CMake support if you like. I'll help you either way. But<br>
> > autotools is a must have.<br>
> ><br>
> I like CMake, and the C++ part of my module is pretty small and simple.<br>
> I have a feeling it won't take much time. If I encounter any problems I'll<br>
> write to you.<br>
><br>
> ><br>
> > Thanks for posting your plan, though it is kind of wage.<br>
> > I would like to more details in the table. Either per default or<br>
> > hidden until you hover over a specific area or click a link.<br>
> > The details would be:<br>
> > - date and time<br>
> > - git revision hash<br>
> > - if possible compiler, compiler version, and compiler flags<br>
> > - maybe compile time?<br>
> ><br>
> > Would it be possible to add a graph for the memory consumption,<br>
> > too?<br>
> > And if the table could be sorted by clicking on the table header<br>
> > would be useful, too.<br>
> > But I think these ideas are for a later stage and to polish the<br>
> > output. First we need the basic functions.<br>
> ><br>
> Yes, a vague plan is suitable for a blog post. I'll try to put more details<br>
> here.<br>
>  - First, now the procedure of measure->store->show is working, the next<br>
> thing is adding more data.<br>
> Memory consumption is already measured, and I've already added a separate<br>
> graph for it.<br>
><br>
>  - Date and time are also already measured, just not displayed, so I will<br>
> add this today.<br>
> Git revision is more tricky, as it's only useful for built-in tests.<br>
> I was thinking of adding the option of specifying some details at runtime,<br>
> such as problem size.<br>
> Perhaps the same should be done for git revision as well.<br>
><br>
>  - Complile time is more complicated, because we have to combine two<br>
> commands.<br>
> Usually you compile and run separately, with different commands, and there<br>
> has to be a way of connecting the two.<br>
> I could make it a runtime arguments as well, but I doubt many people would<br>
> be happy running like this:<br>
><br>
> cd mycoolprog<br>
> ./perftest --program "MyCoolProg" make<br>
> ./perftest --program "MyCoolProg" ./mycoolprog<br>
><br>
> My best idea about this is having configuration files.<br>
> Something like .ini (or .desktop) files should do, like so<br>
><br>
> [Dune Perftest Configuration]<br>
> ProgramName="MyCoolProg"<br>
> CompileCommand="make"<br>
> RunCommand="./mycoolprog"<br>
><br>
> // Extra data that will just be added to the measurement result<br>
> Compiler="GCC"<br>
> CompilerFlags="-O3"<br>
> <with possibility of specifying other data here><br>
><br>
> I'm not sure about this, any suggestions?<br>
><br>
> So, my timeline for this week is<br>
>  - convert the docs to Doxygen, and make it optional<br>
>  - add memory consumption to graphs (already done).<br>
>  - automated (as in, just calling one command) running of built-in tests.<br>
>  - statistics (only mean, stdev for outliers, and linear trends)<br>
</blockquote></div><br></div></div>