ucl-ingi / lepl1402 Goto Github PK

Hello @AlexandreDubray,

If you want that exercise AbstractClass (and others in the future with this kind) to be more "tolerant" to students errors, here are a few tips on how to do it with an example :

1. Replace all .class invocations by Class.forName() (that is what causes students to see message "You modified ..." )
2. Add multiple Exception handlers (mainly ClassNotFoundException and NoSuchMethodError )

Example :

try {
   String classNameWithPackage = "templates.Shape";
   Class shapeClass = Class.forName(classNameWithPackage);
   Method my_method = shapeClass.getDeclaredMethod("getArea", double.class);
   // ... Some piece of code later ...
   throw new CustomGradingResult(TestStatus.SUCCESS,1, "You defined a class Shape with a method called getArea")
} catch(ClassNotFoundException err) {
   throw new CustomGradingResult(TestStatus.FAILED, 0, "Shape class not found");
} catch(NoSuchMethodError err) {
   throw new CustomGradingResult(TestStatus.FAILED, 0, "Shape method getArea cannot be found");
} catch(Exception err) {
   if (err instanceof CustomGradingResult) {
       throw err;
   }
   throw new CustomGradingResult(TestStatus.FAILED, 0, "Unexpected error");
}

PS: As I'm busy with work, I can't make any PR for a long time.

**This issue relates to #35 ** (should probably be a subtask of it).

The FTree expects a depth of 0 for leaves. This is not correct as a leaf is a (sub)tree comprising one single node. Therefore, it has a depth 1.

Also, rather than relying on left() == null && right() == null it would be better if all nodes implemented an isLeaf() method. That way, leaves could be a Tree implementation totally separated from the Node class. This would be way more functional (akin to the Nil in functional lists).

In module 6, we introduce the students to multi-threading programming.
In the exercises, it is diffcult to actually test if they use or not multiple threads. And even if they use multiple threads, are they doing what they should be doing?

It seems that we can access the runtime stack trace of the threads using this method.

We should investigate how this can be translated in the exercise.

This issue relates to #35 (actually this should be a subtask of the previous).

Streams 2 is "stringly typed" this is not how we should teach students to code.
The easiest and cleanest way to solve all questions si to define the following method:

private final static Predicate<Student> pred(final Map<String, Predicate<?>> conditions) {
    return (s) -> {
      for (Map.Entry<String, Predicate<?>> e : conditions.entrySet()) {
        switch (e.getKey()) {
          case "firstName":
            if (!((Predicate<String>) e.getValue()).test(s.getFirstName()))
              return false;
            else break;
          case "lastName":
            if (!((Predicate<String>) e.getValue()).test(s.getLastName()))
              return false;
            else break;
          case "section":
            if (!((Predicate<Integer>) e.getValue()).test(s.getSection()))
              return false;
            else break;
          case "courses_results":
            if (!((Predicate<Map<String, Double>>) e.getValue()).test(s.getCourses_results()))
              return false;
            else break;
          default:
            throw new RuntimeException("Unexpected key");
        }
      }

      return true;
    };
  }

One should rely on the type system to help student get a grasp on what should be done. Also, it would be great if we could show students how to combine predicates (and, or, not, ...)

The exercices on streams should be easier. At least we should make some exercises that introduce the students gently to the stream API and functionnality.
If we want to make some harder exercises, it is fine but, at the moment, the structures of the exercises are too complicated and some unwanted behaviour happened (e.g. different feedback on INGInious for the same code).

The current structure of this exercise allows the student to do the the for loops to filter the elements in the visitor.
But in the tests, we check that it is done in the visitable.
We need to force them to do it in the visitable or it creates confusion since the output is still valid

This issue relates to #35 (subtask)

One should use a "Nil" object rather than null. It would make the code sooooo much cleaner.

Hello,

Since the last time I fetched and uploaded exercises on this github repository ( 26/11/2019 ) , some exercises may have been updated. It might be a good idea to have a recent backup here ;)

This exercise need a refactor.

• Should use Observer/Observable from java librairy
• Do not need a "generic" Pair class... (which should be renamed as well)

This issue relates to #38 but is not a complete duplicate of it

Despite being titled "Visitor..." and forcing the implementation of two methods accept and visit, the pattern which need to be implemented in this exercise is a fancy variation of the Composite pattern. Not the Visitor.

This, for instance, is illustrated by the fact that Visitor interface comprises only two signatures for the visit method. One is visit(Object), the other is visit(Visitable). In a true visitor pattern, one would expect the definition of a visit method for each and every type that might be encountered by the visitor. Also, all those types should be implementing an acceptmethod, otherwise no double dispatch is possible. Here, it is easy to see that one cannot just modify Object to force it to implement accept. Also, that would not make much sense since in java "everything is an object". Thus, this would mean that the visitor is universal and all other types would no longer need to implement accept; thereby defeating the double dispatch purpose of the pattern.

Here is what you will need to do to integrate the plagiarism tool JPlag into our generic run script :

1. Creates a new function inside helper.py :

# Find all java files
def find_files_in_path(path):
    base_folder = Path(path)
    files = Path(path).rglob("*{}".format(FILE_EXTENSION)) if base_folder.exists() else []
    return { 
        relative_path(file)
        for file in files
    }

2. Modify these two lines of method run_command :

def run_command(cmd, cwd=None):
    proc = subprocess.Popen(cmd, cwd=cwd ,shell=True, stderr=subprocess.PIPE, stdout=subprocess.PIPE)

To :

def run_command(cmd, cwd=None, universal_newlines=None):
    proc = subprocess.Popen(cmd, cwd=cwd ,shell=True, stderr=subprocess.PIPE, stdout=subprocess.PIPE, universal_newlines=universal_newlines)

3. Add these lines of code at the end of runfile.py (after "Show and handle results") :

# Don't forget to add this import statment at the top of the file : 
#           from inginious import input
student_name = input.get_input("@username")

# The files filled by the student are all inside PATH_TEMPLATES
files_to_be_tested = helper.find_files_in_path(PATH_TEMPLATES)

# Creates the archive like expected by JPlag 
for student_file in files_to_be_tested:
   command = "archive -a {} -o {}".format(student_file, student_name)
   helper.run_command(command, universal_newlines=True)

Documentation :

Inginious - archive
Inginious - JPlag

**This issue relates to #35 ** (should probably be a subtask of it).

This exercise is a wrong use case of the visitor pattern. The appropriate pattern to use here is the Interpreter pattern.
While it is true that one can implement a grammar-like interpretation with a visitor, this is pretty artificial and forces to break encapsulation. (Encapsulation breakage is the major inconvenient of Visitor pattern and built in it).

An exercise about the visitor pattern should start by recalling what double dispatch is and provide an example that requires it.