Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Directory-level regex matching in MOSS #366

Open
RONNCC opened this issue Mar 4, 2015 · 11 comments
Open

Directory-level regex matching in MOSS #366

RONNCC opened this issue Mar 4, 2015 · 11 comments

Comments

@RONNCC
Copy link

RONNCC commented Mar 4, 2015

Can you add support for file or directory level matching with full regex's in the Moss submission script in the style of a .gitignore.

E.g. if you have (after extracting) /a/b/c/d.txt you can use a regex to say /c/d.txt or */e/ only . Similarly you could filter on the files as a result. Also the ability to do negative searches - e.g. regex does not match, or support for negative lookaheads would be useful.

Hence you could exclude files_given_to_student/*.py

@dlbucci
Copy link
Member

dlbucci commented Mar 4, 2015

I'm confused. We have a filename field that appears under the assessments you choose to run moss on, and I think that already does exactly what you're describing (minus the negative regex stuff). That filename is what is passed to the mossnet call, so the files that get fixed are really up to that program.

@RONNCC
Copy link
Author

RONNCC commented Mar 4, 2015

sorry i wasn't sure if it was bash style pattern globs - or full regex's.

I'm not sure how to 'exclude' files without a full regex :/ also this works on a per file level I believe rather than being able to exclude whole directories

@dlbucci
Copy link
Member

dlbucci commented Mar 4, 2015

I'm pretty sure moss is only useful if the files you send are all the same/serving the same purpose. Like, if you have an assessment with two files, foo.py and bar.py. It's not gonna make sense to compare foo.py files to bar.py files.

@RONNCC
Copy link
Author

RONNCC commented Mar 4, 2015

yes but if they turn in a directory of files, and we gave 2 of those to them (hence everyone has it), that's not very useful with respect to cheat comparisons and causes false positives

@dlbucci
Copy link
Member

dlbucci commented Mar 4, 2015

Right, but you shouldn't really be sending entire directories of files anyway, right? Is there a specific answer.py file that everyone is filling out? Just send that.

@RONNCC
Copy link
Author

RONNCC commented Mar 4, 2015

uhh.. no Moss seems to be fine with it / has it as an example - and nope just like 112 they submit a bunch of files - putting everything in one file being bad style

@dlbucci
Copy link
Member

dlbucci commented Mar 4, 2015

Do you know the file names? Like will there always be a problem1.py, problem2.py, etc?

@RONNCC
Copy link
Author

RONNCC commented Mar 4, 2015

nope ~ there's no regularity to it

@dlbucci
Copy link
Member

dlbucci commented Mar 4, 2015

I'll look into ways we can accommodate this, but I'd suggest putting course files into different directories/not having students submit those files for future assessments.
How do you guys autograde assessments if there's no regularity to the files that are submitted?

@RONNCC
Copy link
Author

RONNCC commented Apr 7, 2015

Yes I think this uses the built in generic bash globbing (correct me if i'm wrong) - i would prefer full regex support - e.g. negative lookaheads to ignore all something_test.py files

@zyx-billy
Copy link
Member

Yes, the user input is passed as argument directly, so standard bash globbing is performed on it.
It doesn't seem hard to implement regex if that turns out to be useful. We can just perform the check as we extract files from the student's submitted archive (in CoursesController::extract_asmt_for_moss).

One odd thing though: the directory structure is flattened when the archive is extracted ('/' replaced with '-'). This isn't mentioned anywhere on the moss page, which means the paths users entered likely won't do what they'd expect. Would be great if someone knows why this was done in the first place when implemented in #357.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants