[Dune-devel] GSoc update

[Christian Engwer]

Hi Miha,

Now a (much) longer reply :-)

First I'd like to state that I'm happy that we have a working
prototype... but obviously there is still some work to do

> Running programs and static HTML code generation now work, and I
> believe it's time to start work on a dynamic "web application" where
> one can filter the results by program, machine or something else.
> 
> Of course, since the review week is upon us, if you wish I can wait with
> that
> and instead write the so-far missing documentation, and maybe add more
> data to measurements.

Adding some more documentation is always good, as we have to keep
things maintainable and it will become harder and harder to add the
documentation.

Currently it is really hard to get into your code, because is nearly
totally undocumented. You are using speaking function names, but still
a bit more details on the semantics and the parameters is welcome.

> > > results. The procedure is described in the README file, it is not
> > > complicated but both Bootstrap and Dygraphs have to be in the correct
> > > locations. I hope this will make it easier for you to review and provide
> > > feedback.
> >
> > On the long run it would be convinient to include some simple
> > configure tests to check for the necessary python and third-party
> > libraries. I'm not a license expert, but I would be very convinient to
> > include as many libs in the repo as possible and add a short
> > description or script to update them :-)
> >
> Dygraphs and Bootstrap are licensed under MIT and Apache licenses,
> respectively.
> I don't think there would be problem if we included them in the repo,
> but we should explicitely mention their licenses.

This will require a proper license file (we should have it
anyway). This file should include a list of contributors, the general
license (preferably the same as the rest of Dune: GPL+ and GPL+runtime
exception for C++ code) and the exceptions.

> Yes, this was a file I forgot to add to the repo. I added the dependencies
> too,
> if there are problem they can be removed and replaced with a script
> that fetches them.

You added a symbolic link for the dygraph-combined.js, pointing to
some non existing directory :-)

Further more I now get an other error:

Traceback (most recent call last):
  File "perftest.py", line 28, in <module>
    perftest(command, "test.log", "test.db")
  File "perftest.py", line 7, in perftest
    data = measure(command)
  File "/home/christi/Uni/Dune/dune-perftest/dune/perftest/measure/measure.py", line 69, in measure
    results.update(computer_parameters())
  File "/home/christi/Uni/Dune/dune-perftest/dune/perftest/measure/measure.py", line 23, in computer_parameters
    p['ram'] = psutil.virtual_memory()[0]
AttributeError: 'module' object has no attribute 'virtual_memory'

Might this be some incompatibility between different versions of
psutil?

It runs after I disable the virtual_memory information.

> The problem with shebangs is that I'm on ArchLinux where python3 is the
> default,
> while I believe some distros still ship with python2 as default.
> I don't think we talked about this, but I make all my code
> python3-compliant,
> and while it should run on python2 as well, there might be some
> incompatibilities.

I think this is solved now?! We can use shebang, as we keep it
compatible with python2 and python3.

Some further comments:

a) A commandline help would be very handy
b) currently all information is written to test.db
c) currently the program tries to write the db in the directory where
   you start it, it would be good to be able to specify this.
d) it doesn't work to call the script from a different directory,
   which will make it difficult to include it into the build or test
   process

Important:

a) The script currently mixes all tests in the output.
   I suggest to create a dedicated html directory, e.g. in the root of
   the current module, and create individual reports in this
   directory.
b) I prefer a separation actions. Therefor you should split the
   program into a data-generation tool, a data-storage tool and a
   html-generation tool.
   I don't think dynamic html is very important, as the data doesn't
   change too often, so it should be enough to generate the html files
   after the nightly run and the just serve static html.
c) Not very difficult, but very convenient... the hover-info should, in
   later versions, include revision numbers, so that we can track the
   cause of a performance regression.

A general question:

a) How do you intend to interact the module with other modules?
   For the beginning I suggest to add some dummy C++ code and add the
   necessary Makefile extensions to your module, so that a
   "make perftest" or similar can test building and running of all
   applications and test programs (see the buildsystem howto on the
   list of Makefile variables to find apps and tests)

One important note at the end!
I'm not available for 2 two weeks (starting from tuesday). So feel
free to ask other people. I'm sure Christoph will be very responsive
as well.

So to conclude, I suggest the following order of actions:

- first add some documentation
- add a list of required python components to the README
- add the license file
- split the program into different components
- update the html generation code to handle different applications
  (for the identification of apps we should use the same
   representation as in dune-autobuild)
- add different dummy-apps to the repo
- automatically collect statistics via the build-system (use automake
  for the beginning)
- add some paranoia tests to the build-system to detect missing
  components as early as possible

Even if I'm not available, you should keep updating the others on your
progress ;-)

Cheers
Christian