[Dune-devel] Regarding GSoC 2013

[Elena Petrevska]

Good Morning Christian,

please not so formal...

I will give my best in adapting to this :).

These days, I was going through the syntax and the way of functioning of
autobuild together with Dune. Please correct me if I am wrong, but this is
what I realized, how it all functions.

So first of all, what I tried to do is to create some Makefiles inside the
autobuild and somehow try to check how it works. It was unsuccessfully. The
next time, I tried something different. Instead of trying to create new, I
used the Makefiles in all dune- * module, which I previously copied to my
pc, and run all tried all the tests you mention in one of the previous
mails. Most of them passed, but sometimes it gave information that "a test
was not run". From there, and from the presentation in the
dune-autobuild/doc/overview (= the presentation I previously found in the
"Publications and Talks") I could understand that actually every module has
its own tests, separate from the others, which I found very practical and
organized. So the user , using "*make <check, sourcescheck, ...>*" actually
accesses the tests, whereas the dune-autobuild is the repository where the
Build Clients input the tests to the Build server, so that the user can use
it alone on her/his own desire. Thus, the user can run whichever test he
wants and all the logs are saved on the pc, along the tests themselves.

Maybe I missed something, maybe I said something incorrect, but by writing
this down in short what how I understood the concept of working, I would
really like to insure my that I completely understood how dune, together
with the dune tests, functions.

sure... I have been discussing, what might be managable within one
GSoC project, this would be something you should think about as
well... we can then discuss this a little bit... it would also
influence where to actually start.

As first, you mentioned in one of the previous mails, that the automated
tests are at this moment not in a good shape. I would really like to start
there, by bringing them in a better shape. Still, these tests are from a
enormous importance regarding the discovery of early problems in the code
and gives more flexibility for changes in the future, which in my opinion,
is of a gread importance.

On the other hand, I was thinking about possible ideas. I saw that in some
of the modules, there are less tests than in some others. As an example, in
dune-common and in dune-grid seemed to me that there were much more tests
than in dune-geometry. I don't know what's the plan, but working with that
type of modules where there are less number of tests, write some tests
about them and then continue improving and writing more tests about the
rest of the modules seems appropriate for me. My idea is that it is good
for all of them should have adequate number of tests, enough for checking a
big part of their functionality.

At this point, after reading your mail this morning, I started thinking of
what tests I should include for the GSoC project, and how much time will be
needed for making them, but also for afterwards, as I (even after GSoC, if
there is a possibility) would definitely like to contribute to the project.

If you think I am wrong, or leading in a wrong direction, please,  do not
hesitate to tell me. I would really like to hear whether I should change
something in the direction that I've taken or the way I understood the
concept.

Thank you in advance,
Regards,
Elena Petrevska
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dune-project.org/pipermail/dune-devel/attachments/20130416/e8779780/attachment.htm>