Commit fb16a1dc authored by Pierre Brandone's avatar Pierre Brandone
Browse files

instructions: refresh the section and archive human evaluation

* source/archive/archive.rst,
* source/archive/defense/defense.rst: Created,
* source/instructions/evaluation/during_the_examination.rst -> source/archive/defense/during_the_examination.rst,
* source/instructions/evaluation/human_evaluation.rst -> source/archive/defense/human_evaluation.rst,
* source/instructions/evaluation/evaluation.rst,
* source/instructions/evaluation/marks_computation.rst,
* source/instructions/groups.rst,
* source/instructions/instructions.rst,
* source/instructions/interactions.rst,
* source/instructions/rules_of_the_game.rst,
* source/instructions/tests/tests.rst: Here.
parent 81c58ebf
Pipeline #32033 passed with stage
in 54 seconds
......@@ -15,4 +15,5 @@ been continuously revised and updated to reflect the latest specifications.
:maxdepth: 1
pthl/pthl
defense/defense
monoburg
.. _Defense:
Defenses
--------
|project| is not evaluated via a defense anymore.
.. **Human Evaluation**: Human evaluation
..
.. **During the examination**: TODOs and not TODOs during the defense
.. toctree::
human_evaluation
during_the_examination
......@@ -9,6 +9,4 @@ both by humans, and a program.
.. toctree::
automated_evaluation
during_the_examination
human_evaluation
marks_computation
......@@ -3,16 +3,17 @@
Marks Computation
-----------------
Because the |Project| Compiler is a project with stages, the
computation of the marks depends on the stages too. To spell it out
explicitly:
**The assistants are not responsible of the marks**.
*A stage is penalized by bad results on tests performed for
previous stages.*
For every submission, all steps from previous stages are re-evaluated. For
example, if you submit a tag for |compiler|-3, the traces of |compiler|-{1,2,3}
will be computed. This gives you an opportunity to improve your previous steps
and fix edge cases.
It means, for instance, that a |COMPILER|-3 compiler will be
exercised on |COMPILER|-1, |COMPILER|-2, and
|COMPILER|-3. If there are still errors on |COMPILER|-1 and
|COMPILER|-2 tests, they will pessimize the result of
|COMPILER|-3 tests. The older the errors are, the more expensive
they are.
Your marks will be computed using your best traces (i.e. most likely your last
step submission).
.. warning::
Even if failing the submission of a step is not a killer move for your
project, having the moulinette test your code and send you traces is a good
many of your predecessors could not have ever dreamed of. Use it wisely!
......@@ -3,105 +3,99 @@
Groups
------
Starting with |compiler|-1, assignments are to be done by groups
of four.
Starting with |compiler|-1, assignments are to be done by groups of four.
The first cause of failures to the |project| project is human
problems within the groups. We cannot stress too much the importance of
constituting a good group of four people. The |project| project
starts way before your first line of code: it begins with the selection
of your partners.
The first cause of failures to the |project| project is human problems within
the groups. We cannot stress too much the importance of constituting a good
group of four people. The |project| project starts way before your first line of
code: it begins with the selection of your partners.
Here are a few tips, collected wisdom from the previous failures.
You work for yourself, not for grades
Yes, we know, when you're a student grades are what matters. But close
your eyes, make a step backwards, and look at yourself for a minute,
from behind. You see a student, some sort of a larva, which will turn
into a grownup. The larva stage lasts 3 to 4 years, while the hard
working social insect is there for 40+ years: a 5% ratio without the
internships. Three minutes out of an hour. These years are made to
prepare you to the rest of your life, to provide you with what it takes
to enjoy a lifelong success in jobs. So don't waste these three
minutes by just cheating, paying little attention to what you are given,
or by just waiting for this to end. The opportunity to learn is a
unique moment in life: treasure it, even if it hurts, if it's hard,
because you may well regret these three minutes for much of your life.
Start recruiting early
Making a team is not easy. Take the time to know the people, talk with
them, and prepare your group way before beginning the project.
Making a team is not easy. Take the time to know the people, talk with them,
and prepare your group way before the beginning of the project.
Don't recruit good lazy friends
If s/he's lazy, you'll have to scold her/him. If s/he's a friend, that
will be hard. Plus it will be even harder to report your problems to
us.
If s/he's lazy, you'll have to scold her/him. If s/he's a friend, that will be
hard. Plus it will be even harder to report your problems to us.
Recruit people you can depend on
Trust should be your first criterion.
Members should have similar programming skills
You work for yourself, not for grades
Yes, we know, when you're a student grades are what matters. But close your
eyes, make a step backwards, and look at yourself for a minute, from behind.
You see a student, some sort of a larva, which will turn into a grownup. The
larva stage lasts 3 to 4 years, while the hard working social insect is there
for 40+ years: a 5% ratio without the internships. Three minutes out of an
hour. These years are made to prepare you to the rest of your life, to provide
you with what it takes to enjoy a lifelong success in jobs. So don't waste
these three minutes by just cheating, paying little attention to what you are
given, or by just waiting for this to end. The opportunity to learn is a
unique moment in life: treasure it, even if it hurts, if it's hard, because
you may well regret these three minutes for much of your life.
Weak programmers should run away from skilled programmers
The worst "good idea" is "I'm a poor programmer, I should be in a
group of skilled programmers: I will learn a lot from them".
Experience shows this is wrong. What actually happens is as follows.
At the first stage, the leader assigns you a task. You try and fail,
for weeks. In the meanwhile, the other members teach you lots of facts,
but (i) you can't memorize everything and end up saying "hum hum"
without having understood, and (ii) because they don't understand what
you don't understand, they are often poor teachers. The day before the
submission, the leader does your assignments to save the group. You
learned nothing, or quite. Second stage: same beginning, you are left
with your assignment, but the other members are now bothered by your
asking questions: why should they answer, since you don't understand
what they say (remember: they are poor teachers because they don't
understand your problems), and you don't seem to remember anything! The
day before the submission, they do your work. From now on, they won't
even ask you for anything: "fixing" you is much more time consuming
than just doing it by themselves. Oral examinations reveal you neither
understand nor do anything, hence your grades are bad, and you win
another round of first year...
Take our advice: if you have difficulties with programming, be with other
people like you. Your chances are better together, and anyway you are
allowed to ask for assistance from other groups.
Don't mix repeaters with first year students
Repeaters have a much better understanding of the project than they
think: they know its history, some parts of the code, etc. This will
introduce a difference of skills from the beginning, which will remain
till the end. It will result in the first year students having not
participated enough to learn what was to be learned.
Don't pick up old code
This item is especially intended to repeaters: you might be tempted to
keep the code from last year, believing this will spare you some work.
It may not be so. Indeed, every year the specifications and the
provided code change, sometimes with dramatic impact on the whole
project. Struggling with an old code base to meet the new standard is a
long, error prone, and uninteresting work. You might spend more time
trying to preserve your old code than what is actually needed to
implement the project from scratch. Not to mention that of course the
latter has a much stronger educational impact.
Members should have similar programming skills
Weak programmers should run away from skilled programmers
The worst "good idea" is "I'm a poor programmer, I should be in a group o
skilled programmers: I will learn a lot from them". Experience shows this is
wrong. What actually happens is as follows.
At the first stage, the leader assigns you a task. You try and fail, for
weeks. In the meanwhile, the other members teach you lots of facts, but (i)
you can't memorize everything and end up saying "hum hum" without having
understood, and (ii) because they don't understand what you don't
understand, they are often poor teachers. The day before the submission,
the leader does your assignments to save the group. You learned nothing, or
quite. Second stage: same beginning, you are left with your assignment, but
the other members are now bothered by you asking questions: why should they
answer, since you don't understand what they say (remember: they are poor
teachers because they don't understand your problems), and you don't seem to
remember anything! The day before the submission, they do your work. From
now on, they won't even ask you for anything: "fixing" you is much more time
consuming than just doing it by themselves. Code reviews reveal you neither
understand nor do anything, hence you learned nothing from the project and
got yourself the need to find a new group for the next project.
Take our advice: if you have difficulties with programming, be with other
people like you. Your chances are better together, and anyway you are
allowed to ask for assistance from other groups.
Don't mix repeaters with first year students
Repeaters have a much better understanding of the project than they think:
they know its history, some parts of the code, etc. This will introduce a
difference of skills from the beginning, which will remain till the end.
It will result in the first year students having not participated enough to
learn what was to be learned.
Don't pick up old code
This item is especially intended to repeaters: you might be tempted to keep
the code from last year, believing this will spare you some work. It may not
be so. Indeed, every year the specifications and the provided code change,
sometimes with dramatic impact on the whole project. Struggling with an old
code base to meet the new standard is a long, error prone, and uninteresting
work. You might spend more time trying to preserve your old code than what
is actually needed to implement the project from scratch. Not to mention
that of course the latter has a much stronger educational impact.
Diagnose and cure drifts
When a dysfunction appears, fix it, don't let it grow. For instance, if
a member never works in spite of the warnings, don't cover him: he will
have the whole group drown. It usually starts with one member making
more work on |project|, less on the rest of the curriculum, and
then he gets tired all the time, with bad mood etc. Don't walk that
way: denounce the problems, send ultimatums to this person, and
finally, warn the assistants you need to reconfigure your group.
When a dysfunction appears, fix it, don't let it grow. For instance, if a
member never works in spite of the warnings, don't cover him: he will have the
whole group drown. It usually starts with one member making more work on
|project|, less on the rest of the curriculum, and then he gets tired all the
time, with bad mood etc. Don't walk that way: denounce the problems, send
ultimatums to this person, and finally, warn the assistants you need to
reconfigure your group.
Reconfigure groups when needed
Members can leave a group for many reasons: dropped EPITA, dropped
|project|, joined one of the schools' laboratories, etc. If your group is
seriously unbalanced (three skilled people is OK, otherwise be four),
ask for a reconfiguration in the news.
|project| is a part of your curriculum
|project| should neither be 0 nor 100% of your curriculum: find
the balance. It is not easy to find it, but that's precisely one thing
EPITA teaches: balancing overloads.
Members can leave a group for many reasons: dropped EPITA, dropped |project|,
joined one of the schools' laboratories, etc. If your group is seriously
unbalanced (three skilled people is OK, otherwise be four), ask for a
reconfiguration in the news.
|project| is **a part** of your curriculum
|project| should neither be 0 nor 100% of your curriculum: find the balance.
It is not easy to find it, but that's precisely one thing EPITA teaches:
balancing overloads.
......@@ -3,6 +3,9 @@
Instructions
============
This sections contains informations regarding how you should work on |Project|,
as well as how to behave during the project.
.. toctree::
interactions
......
......@@ -7,10 +7,14 @@ Bear in mind that if you are writing, it is to be read, so pay attention
to your reader.
The right place
Using mails is almost always wrong: first ask around you, then try to find the
assistants in their lab, and finally post into :code:`assistants.tiger`. You
need to have a very good reason to send a message to the assistants or to
Akim and Etienne, as it usually annoys us, which is not in your interest.
Contacting an assistant outside debugs is almost always wrong: first ask
around you, then, depending on the issue, try to find the assistants in their
lab; and/or post a news into :code:`assistants.tiger`. You need to have a very
good reason to send a message to the assistants or to Etienne, as it usually
annoys us, which is not in your interest. If your question is about a trace
not clear or a specific test case on a dementor or a submission, and **after
having shown the problem to an assistant** you can send a ticket to the
moulettes.
The newsgroup :code:`assistants.tiger` is dedicated to the Compiler
Construction lecture, the |project| project, and related matters (e.g.
......@@ -28,29 +32,28 @@ A meaningful title
+-----------------+------------------------------+
A legal content
Pieces of critical code (e.g., precedence section in the parser, the
string handling in the scanner, or whatever *you* are supposed to
find by yourself) are not to be published.
Pieces of critical code (e.g., precedence section in the parser, the string
handling in the scanner, or whatever *you* are supposed to find by yourself)
are not to be published.
This includes the test cases. While posting a simple test case is
tolerated, sending many of them, or simply one that addresses a specific
common failure (e.g., some obscure cases for escapes) is strictly
This includes the test cases. While posting a simple test case is tolerated to
illustrate your question, sending many of them, or simply one that addresses
a specific common failure (e.g., some obscure cases for escapes) is strictly
forbidden.
A complete content
If you experience a problem that you fail to solve, make a report as
complete as possible: include pieces of code (**unless the code is
critical and shall not be published**) and the full error message from
the compiler/tool. The following text by Simon Tatham is enlightening;
its scope goes way beyond the |project| Project:
`How to Report Bugs Effectively
If you experience a problem that you fail to solve, make a report as complete
as possible: include pieces of code (**unless the code is critical and shall
not be published**) and the full error message from the compiler/tool. The
following text by Simon Tatham is enlightening; its scope goes way beyond the
|Project| Project: `How to Report Bugs Effectively
<http://www.chiark.greenend.org.uk/~sgtatham/bugs.html>`_. See also
:ref:`How not to go about a programming assignment
<How not to go about a programming assignment>`, item "Be clever when using
electronic mail".
A legible content
Use French or English. Epitean is definitely not a language.
Use French or English. Epitean is definitely not a language.
A pertinent content
Trolls are not welcome.
......@@ -3,32 +3,27 @@
Rules of the Game
-----------------
As any other assignment, |project| Project comes with its rules to
follow.
**Rule: Thou Shalt Not Copy Code**
**Rule: Thou Shalt Not Possess Thy Neighbor's Code**
It is *strictly* forbidden to possess code that is not yours. You
are encouraged to work with others, but don't get a copy of their code.
See :ref:`How not to go about a programming assignment
<How not to go about a programming assignment>`, for more hints on
what will *not* be accepted.
**Rule: Tests are part of the project**
**Rule: Do not copy tests or test frame works**
Test cases and test engines development are parts of the |project|
Project. As such the same rules apply as for code.
**Rule: If something is fishy, say it**
If something illegal happened in the course of a stage, let us know,
arrangements *might* be possible. If *we* find out, the rules
will be strictly applied. It already happened that third year students
have had to redo the |project| Project because their code was found in
another group: -42/20 is seldom benign.
**Rule: Don't hesitate working with other groups**
Don't bother everybody instead of trying first. Conversely, once you
did your best, don't hesitate working with others.
As any other assignment, |project| comes with its rules to follow.
**Thou Shalt Not Copy Code Nor Possess Thy Neighbor's Code**
It is *strictly* forbidden to possess code that is not yours. You are
encouraged to work with others, but don't get a copy of their code and don't
show or stream your code. See
:ref:`How not to go about a programming assignment
<How not to go about a programming assignment>`, for more hints on what will
*not* be accepted.
**Tests are part of the project, do not copy tests or test frameworks**
Test cases and test engines development are parts of the |project| Project.
As such the same rules apply as for code.
**If something is fishy, say it**
If something illegal happened in the course of a stage, let us know,
arrangements *might* be possible. If *we* find out, the rules will be strictly
applied. It already happened that third year students have had to redo the
|project| Project because their code was found in another group: -42/20 and a
convocation to the assistants' lab is seldom benign.
**Do not hesitate working with other groups**
Don't bother everybody instead of trying first. Conversely, once you did your
best, don't hesitate working with others.
......@@ -3,12 +3,14 @@
Tests
=====
As stated in :ref:`Rules_of_the_Game`, writing a test framework and tests
is part of the exercise.
As stated in :ref:`Rules_of_the_Game`, writing a test framework and tests is
part of the exercise. You may be refused a debug if it is clear you made no
effort in writing a test suite as it can be a tool for assistants to help you
debug your code.
As a starting point, we provide a tarball containing a few
|Project| files, see :ref:`Given Test Cases`. **They are not
enough**: your test suite should be continually expanding.
As a starting point, we provide a tarball containing a few |Project| files, see
:ref:`Given Test Cases`. **They are not enough**: your test suite should be
continually expanding.
.. toctree::
......
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment