OctaveCodeQuestion type

[davis68]

I have created a working OctaveCodeQuestion type using Oct2Py. You can see it at https://github.com/davis68/relate for now. I haven't created a PR yet for it.

• It uses data_files to include M-files for supporting functions.

• It has its own new image for Octave. (This is currently messy since I kept a quick update to the image around for development purposes, but once you're satisfied with the extension I will flatten those files into one.)

The following works correctly:

type: OctaveCodeQuestion
id: test_apply_function
value: 1
timeout: 10
title: "Checkpoint:  Applying a Function"
access_rules:
    add_permissions:
        - see_correctness
        - change_answer

prompt: |
    ### Applying a Function

    Apply the provided function `f` to the provided array `x`.  Store the result in `y`.

    (`x` has the value `[ 1 2 3 4 5 ]` but is already defined and available for you.)

setup_code: |
    x = [ 1 2 3 4 5 ];

initial_code: |
    y = f( ___ );

names_for_user: [ x ]

names_from_user: [ y ]

data_files: [ "./question-data/f.m" ]

test_code: |
    pts = 0.0

    try:
        import oct2py
        from oct2py import Struct,Cell,StructArray

        import numpy as np

        oc = oct2py.Oct2Py()
        test_y = oc.eval( "[ 1 2 3 4 5 ].^2;" )
        print(test_y,y )

        assert np.allclose( y,test_y )
        pts = 1.0

    except NameError:
        feedback.finish( 0.0,'Something is wrong.  Have you created `y`?' )
    except AssertionError:
        feedback.finish( 0.0,'Something is wrong.  Have you used `f` on `x` to obtain `y`?' )

    if np.isclose( pts,1.0 ):
        feedback.finish( pts,'Success!' )
    else:
        feedback.finish( pts,'Keep trying.  If you get stuck, please ask a TA for help on Piazza or office hours.' )


correct_code: |
    y = f(x);

What additional documentation and tests would you like to see as part of the PR?

[davis68]

I have used oc and octave as direct analogues of py and python throughout if you are grepping through.

[davis68]

One quirk is that setup_code and initial_code are in Octave/MATLAB, while test_code is in Python.

[davis68]

@inducer I have some time this week and next to rework this so that it passes the CI tests.

I'm going to put together three separate PRs:

1. CodeQuestion (splitting PythonCodeQuestion off into a subclass) This shouldn't change functionality at all.
2. Docker split-out. This will be a fairly involved change.
3. OctaveCodeQuestion (and infrastructure for other code types) I probably won't make a human-graded version right now.

The main architectural difference is Docker. Most of the Docker infrastructure is hard-coded rather than pulled from config, so that will represent the most major change in the way RELATE works. Since you haven't seen code yet, I won't ask for too much commentary, but it's a heads-up that I'll be proposing some changes there.

[inducer]

I have some time this week and next to rework this so that it passes the CI tests.

Great! Sorry that I've been a bit absent here. I'm definitely on board with getting this going on the Illinois instance before the semester starts.

[davis68]

See #667 for point number one above.

[davis68]

For point number two:

1. inducer/relate-runpy-amd64 makes and requires frequent reference to things like runpy (user and code). I propose changing this to runcode uniformly. This will break compatibility unless RELATE starts to specify image versions or you opt to switch to a new name or specific tag for forthcoming Docker images.
2. After that change, I have created a compatible davis68/relate-octave image. I am willing to commit to maintain this image indefinitely. Alternatively, I can pass it over to something that lives under inducer on DockerHub if you prefer to retain control.

Strictly speaking the only change I need to make for number two is to alter the Docker infrastructure (item 1). Item 2 can be deferred until change number three with the implementation of OctaveCodeQuestion.

[davis68]

@inducer ☝️ also please see the previous note about Docker changes either breaking compatibility or persisting with an incongruous naming in runpy etc.

[inducer]

• I agree with your suggestion of using runcode for containers that speak the (former) runpy "protocol".
• I am OK with a compatibility break. To avoid obnoxious error messages, I think it would be useful to change the initial "ping" request to something that also returns the version of the protocol spoken by the container. If there isn't one (or it doesn't match expectations), an actionable error message can be produced this way.
• I'm happy to have the default Octave container be yours. (I'm guessing you'll be more intrinsically motivated to maintain it. :P) I can't seem to see your container description currently (500 Server Error on Docker Hub), but it would be fantastic if you could make sure it points to the repo with the source. I'll do the same with mine.
• While we're at it, I think a useful feature would be to let a code page specify the container name it would like to use. There's resource use concern on the runners connected with that, but I'm willing to leave that unhandled for the moment.

[davis68]

👍

https://hub.docker.com/r/davis68/relate-octave, FWIW (I linked the account-internal view which for some reason is different.)

[davis68]

• Straightforward.
• Right now it looks like inducer/relate-runpy-amd64 only has a latest tag. Can you post a, say, legacy tag to differentiate?
• 👍
• Will keep in mind. Probably not in the initial version but can implement downstream.

[inducer]

Right now it looks like inducer/relate-runpy-amd64 only has a latest tag. Can you post a, say, legacy tag to differentiate?

Not sure I understand. I figured I would have a inducer/relate-runpy-v2-amd64 for the new protocol, to avoid confusion. Tags are a little less robust IMO.

[davis68]

Got it. To top it off, it looks like there's not a good way to query the tag via the Python interface anyway.

[davis68]

@inducer Is the Dockerfile for inducer/debian-amd64-minbase available online or can you share?

Fresh image builds encounter the error message

E: The repository 'http://security.debian.org testing/updates Release' does not have a Release file.

so to test my changes locally I'll need to change the upstream base image.

[inducer]

It doesn't come from a Dockerfile. Instead, Debian ships with a script to produce the image. On a Debian host, you can run

/usr/share/docker.io/contrib/mkimage.sh -t inducer/debian-amd64-minbase debootstrap --arch=amd64 --variant=minbase testing 

to produce the image. I've built and pushed an updated version. Hope that helps.