I'd like the README to have a clear depiction of what this project is about and for. Especially as this is a good resource reference for a resume.

I don't program in Elixir but just getting a script to run or compile should be easy… right? Well as it turns out there are limitations with the way we do things that don't agree with Elixir.

For just running an Elixir script we'd use iex. But that currently has an issue with having input given too quickly ( see elixir-lang/elixir#3741 ). So if we want to do it that way we'd need to delay input injection to STDIO until it's ready.

If we want to compile and then run the executable we have to write a custom project definition script for what they have named escript. After doing that the student team would have to write their code with the same module name as what set up in the script with a main method. So in other words we'd need to provide the students with a template starting script. For an excellent how-to on compiling Elixir via escript see this post: http://ieftimov.com/writing-elixir-cli-apps

So this is doable — but some decisions need to be made on the implementation. So this thread is open for discussion.

will display:

• time remaining
• status of submissions
• status of problems
• any penalties

admins adding a new problem is probably our most complex view. We need to know if there are multiple input/output pairs, and we'll probably need some js support if multiple pairs need to be supported.

Things we do know:

• problem name field
• file upload for solution source file
• file upload for printable assets

Implementing new runners (especially writing the specs) would be easier if there was a standard test problem. I like the pig latin one Daniel's got in his tests, because it's dead simple to implement solutions for.

I see CoC 1.3.0 has been approved. If I may add I really like the direction Matz went with the CoC discussion in choosing the PostrgreSQL CoC (The Ruby Community Conduct Guideline) which has one important statement this CoC doesn't include:

When interpreting the words and actions of others, participants should always assume good intentions.

The current CoC here doesn't reflect “assuming the best” or give any statement as to trying to make amends. This CoC strictly focuses on negative aspects and enforcement. So whereas I'm okay with the policy itself — I don't feel it properly reflects a positive ideology for keeping the peace.

rails g submission_runner:lang for a start. Maybe add some way to provide the extension?

This probably depends on #121

How do we actually want to go about:

1. Making this available to people?
2. Deploying it to actual systems?

on:

• show submission
• team dashboard
• admin dashboard?

@cflipse has said he has no problem with the approach sketched in the question (not the solution) here: http://stackoverflow.com/questions/2170372/writing-a-meta-refresh-method-for-rails

Working proper code with good or bad results works just fine in evaluating results from the submission runner.

When the code to be executed is asdf then only comparing the output file to the stdout will tell you that it failed. Everything else says it passes. When I experiment on my computer the exit status is a non zero number but it's not resulting that way in the docker run.

In case you weren't aware I was joking when I asked about merging directly to master. Have no worries about me doing any such thing. I would appreciate higher repo privileges.

The job output comparison needs to be made modular. There are 5 options PCSqared supports. We should figure out what those are, and then implement them.

The code works, it's clean, and any refactoring that needs to be done may effect multiple runners so if the code base starts getting modified on refactors now the merge master madness will start all over again.

columns:

• team name
• first problem
  ...
• last problem
• penalties
• score ?

probably put it in the seeds file

I don't think there's a lot of benefit to keeping them out of app/, and putting them there gives us some minor advantages:

1. less typing
2. rake tasks already have them loaded
3. more Railsy

@danielpclark

None of Docker::EntryFile, Docker::InputFile, Docker::OutputFile, Docker::ResultFile, Docker::IOFile are necessary. We don't need to build &/ run in a temp directory--building in the submission directory and persisting any compilation artifacts provides more of an audit trail should that be necessary. Everything else these classes provide is redundant given that SubmissionRunner::Base#source_file returns a Pathname object. This is born out by the fact that the Java runner, which uses none of this machinery, works.

Support::InterpretativeLanguage::MockResult is a good solution to the design flaw I left in SubmissionRunner::Base, and it should be moved into the runner namespace.

Support::InterpretiveLanguage itself strikes me as too much DRY too quickly. We've only had this domain model in our heads for a weekend. I think it's too early to completely remove the docker_run invocation from Runners. It might be a good idea down the road, but I don't think extracting it from only a certain set of Runners is the right move. There's probably a more comprehensive abstraction that lets us pull that invocation out of all the Runners, but we probably will be less likely to see it if we provide an abstraction to a subset now.

should display which problem they're submitting for, and have a file upload field

https://github.com/danielpclark/stop_watch

What it's good for: Marking time with starting points, marks along the way, and stopping point. This would be useful for competition times and test run times.

This would not be useful for timing out anything that's running too long.

If a student team knows the answer they can simply print the answer out to standard output. We should add a garbage input test to make sure they don't give the originally expected answer in the output when the wrong input has been given.

Participant code could potentially access the internet from running containers on the host if it has internet access. We should block containers from accessing the host's internet connection. And potentially make it configurable by contest.