XML schema for Parsons executable

[Andrew Scholer]

I'm working on how to represent Parsons problems that spawn executable activecodes upon completion and would like some input on schema design for it.

Just adding an @executable to an exercise isn't enough as there are quite possibly a host of other options that the activecode needs. It can get the language from the exercise, but it might need things like @compiler-args, @include, @codelens, etc... Adding all of those to the exercise doesn't feel right.

So I am leaning to executable-area (I don't love that name) as an optional element in an exercise with blocks. Its presence implies that the Parsons should span the activecode. The executable-area can have all the attributes that activecodes can get - they are applied to the activecode that gets created later. Finally, the executable-area can have child elements "prepended" and "appended" that contain text that is added to whatever the student produced in the Parsons problem. 

A mockup is below. Any thoughts and advice is welcome.

        <exercise label="parsons-with-executable" language="cpp" adaptive="yes" indentation="show">
            <title>Parsons Problem with executable</title>
            <statement>
                <p>Write a simple C++ function <c>int foo(int x)</c> that simply applies the function <c>int bar(int x) (from <c>mystery.h</c>) to x and returns the result.</p>
            </statement>
            <blocks>
                <block order="4">
                    <cline>int foo(int x) {</cline>
                </block>
                <block order="2">
                    <cline>    int barResult = bar(x);</cline>
                </block>
                <block order="3">
                    <cline>    return bar;</cline>
                </block>
                <block order="1">
                    <cline>}</cline>
                </block>
            </blocks>
            <executable-area compiler-args="-std=c++17" linker-args="-s" include="mystery.h" datafile="ccdata2.txt" codelens="no">
                <prepended>
                    //extra code before Parsons output
                    #include &lt;iostream&gt;
                    using namespace std;
                   
                </prepended>
                <appended>
                    //extra code after Parsons output

                    int main() {
                        cout &lt;&lt; foo(5) &lt;&lt; endl;
                    }
                </appended>
            </executable-area>

        </exercise>

Andrew Scholer (he/him/his)

Computer Science Instructor/Program Chair

Chemeketa Community College

503.589.7649 

computerscience.chemeketa.edu/people/andrew-scholer/

[Rob Beezer]

Dear Andrew,

A bit brief since on fone. I like the logic leading to #executable-area. I was already going there. And don't love the name either. ;-)

Why not #program? That's what it is? But always becomes an ActiveCode. The pre-processor puts an attribute on the #exercise identifying it as a Parsons problem, so necessary adjustments could be made for this context.

We have a #preamble and #postamble for blocks like #theorem. Not entirely accurate but recycling names is good.

And for static formats you would make what adjustments...?

Rob

[Andrew Scholer]

Nice - I like your names better than what I was working with. 

I wouldn't output anything for static. The point of the new element is to let students try out the code they built after completing the Parsons. All I can think of putting in a static representation is a note that says, "Why are you reading a static version of an interactive programming text???" :)

Andrew Scholer (he/him/his)

Computer Science Instructor/Program Chair

Chemeketa Community College

503.589.7649 

computerscience.chemeketa.edu/people/andrew-scholer/

--
You received this message because you are subscribed to the Google Groups "PreTeXt development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pretext-dev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/pretext-dev/MTAwMDAyMy5iZWV6ZXI.1720458062%40quikprotect.

[Rob Beezer]

> I wouldn't output anything for static.

Well, that is easy.

>I can think of putting in a static representation is a note that says, "Why
>are you reading a static version of an interactive programming text???" :)

Hey!