Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Bradley Miller
    @bnmnetp
    If you could take a look at them and get some fixes. It would be nice to have one PR per fix unless they are really trivial, then I don’t mind if you bundle them.
    Isaiah Mayerchak
    @flysaiah
    I think we're seeing different errors with Parsons. I just checked the page source of the overview page on the example that's not working for me and it has all of the code it should have, it's just not rendering.
        <pre data-component="parsons" id="question1_100_4">
            <span data-question>sc-1-3: Construct a block of code that correctly implements the accumulator pattern.</span>x = 0
    for i in range(10)
       x = x + 1</pre>
    Isaiah Mayerchak
    @flysaiah
    I'm testing by removing specific parts of the new runestonebase and it seems that the block of code that defines the includes method is conflicting somehow with parsons.
    Isaiah Mayerchak
    @flysaiah
    I found the source of the problem--it's very strange, but after lots of console.logs I found that on line 870 of parsonsaux.js (which is where parsons errors out when runestonebase is on the page), the value of permutation[i] is an integer for the first 3 passes in the for loop, and the 4th pass through its value is
    "function Array.includes(searchElement)" which is declared in runestonebase. I have no idea how that is getting into the permutation array, but that's what's happening.
    The array only has 3 elements, but I think because whoever wrote the code for the function is doing iteration by items instead of by position, it is somehow accessing the prototype function of Array as an item in the array.
    Isaiah Mayerchak
    @flysaiah
    I was right: I changed all of the iterations by item to iterations by position (i.e. instead of "for var i in array_" it's now "for (var i = 0; i < _array.length; i++) and parsons is no longer broken. I'm fairly certain the same thing is happening in codelens, which is what is causing it to break too. I'll do a PR on this and on CL too when I fix too.
    Isaiah Mayerchak
    @flysaiah
    It turns out that our new parsons JS currently doesn't support multi-line functionality. We'll have to get that working as well as the Sphinx side.
    Bradley Miller
    @bnmnetp
    ok, good.
    In the meantime, I am removing that polyfill implementation of includes. I don’t know why I didn’t just write if (x in [‘java’, ‘cpp’…]) in the first place.
    Isaiah Mayerchak
    @flysaiah
    Ok. Do you still want me to do a pull request on parsonsaux then? All that does is replace the for loops to prevent the includes conflict.
    Bradley Miller
    @bnmnetp
    No need to do that.
    Bradley Miller
    @bnmnetp
    @flysaiah How is the fix coming for parsons?
    Isaiah Mayerchak
    @flysaiah

    I'm struggling a bit with figuring out why the multi-line isn't working. The Sphinx side is actually working pretty well--most of the code that I deleted from the old parsons.py is functionality that needed to be implemented in the JS, because it was turning multiple line code into single line code with a "\n" replacing the actual newline character, which I should be able to do easily in the JS side. However, even when I hardcode some code in the JS side from an actual working example from the site--for example:

        import turtle\nwindow = turtle.Screen()\nella = turtle.Turtle()

    This should render one draggable parsons element that is multiple lines of code, but when I hardcode it and pass it into the ParsonsWidget object, it actually still renders as one draggable element, but it is one really long line with actual spaces instead of newlines. Also, I realized that in working examples of Parsons on interactivepython.org, all of the draggable code on the parsons problems have their text wrapped in a multitude of <span> elements. It looks like this happens in prettify.js, and we're including it in our test pages, but none of our code is being wrapped in those spans. I'm wondering if these two things are related.

    Bradley Miller
    @bnmnetp
    You might need to replace the \n with a <br /> ?
    In some other components I know that others have resorted to using nl or some other string to indicate a newline as escaping this stuff can be tricky.
    Isaiah Mayerchak
    @flysaiah
    Interesting. Ok, I'll try using different newlines.
    Bradley Miller
    @bnmnetp
    I meant *nl* make sure its something that is unlikely to appear in the code and then replace it with <br />
    Isaiah Mayerchak
    @flysaiah
    Unfortunately, even manually entering <br /> tags into the HTML code isn't creating newlines in the parsons objects--in the <parsons-orig-divid> div, which is where the original code is stored, the <br> tag is definitely present, but it's not doing anything to the element on screen--the <br> is not appearing inside the unordered list that contains each draggable element. The ParsonsWidget should just be grabbing whatever is in that parsons-orig div and turning it into the right element, but I'm not sure what's going wrong. I'll mess around with it some more.
    Isaiah Mayerchak
    @flysaiah
    Somewhere in the parsonsaux.js file, the <br> (or before, the \n) is getting stripped away from the code, and I'm tracing backwords through the code to find where.
    Isaiah Mayerchak
    @flysaiah
    I fixed it! It had to do with the jquery method we were using to pass the original HTML text into the Parsons Widget. Before we were using $(this.origDiv).text() instead of $(this.origDiv).html() to get what we needed, which has been giving us problems in other components too. I have to bring my brother to his tennis event, but will finalize the fix and do a pull request in a few hours.
    Bradley Miller
    @bnmnetp
    Great! Thanks
    Isaiah Mayerchak
    @flysaiah
    One other small bug popped up that I have to fix relating to non-multiple line parsons components, but I'll have it fixed by the end of the night.
    Isaiah Mayerchak
    @flysaiah
    Pull request made.
    Bradley Miller
    @bnmnetp
    Quick question on the shortanswer. In the loadJournal function I do not see any code that would ask the server for anything. the only thing in loadJournal is to get the answer from localStorage. I’m thinking that this is just how you wrote it, but I wanted to be sure I wasn’t missing a commit.
    Isaiah Mayerchak
    @flysaiah
    The loadJournal function code was copied from the original shortanswer.js file--I did not modify it or add any original code.
    Bradley Miller
    @bnmnetp

    @flysaiah there is still a little problem with the parsing of the parsons problems on the sphinx side. Can you find a few minutes to look at this example:

    .. parsonsprob:: question1_100_4
    
       Construct a block of code that correctly implements the accumulator pattern.
       -----
       x = 0
       for i in range(10):
       =====
          x = x + 1
          y = 10
       =====
       print x

    You will see that the y=10 line gets indented several extra spaces in the generated code.

    Isaiah Mayerchak
    @flysaiah
    Yes, I'll look at stripping those extra indents as soon as I can.
    Bradley Miller
    @bnmnetp
    Great. the old parsons.py file took care of it with this:
        def parse_multiline_parsons(self, lines):
            current_block = []
            results = []
            for line in lines:
                if(line == '====='):
                    results.append(self.convert_leading_whitespace_for_block(current_block))
                    current_block = []
                else:
                    current_block.append(line)
            results.append(self.convert_leading_whitespace_for_block(current_block))
            return "\n".join(results)
    
        def convert_leading_whitespace_for_block(self, block):
            whitespaceMatcher = re.compile("^\s*")
            initialWhitespace = whitespaceMatcher.match(block[0]).end()
            result = block[0]
            for line in block[1:]:
                result += '\\n' # not a line break...the literal characters \n
                result += line[initialWhitespace:]
            return result
    But we can’t do that in python anymore that should be done somewhere in parsons.js
    Isaiah Mayerchak
    @flysaiah
    Yes. I have some JS string fornatting currently in place--I'll just have to modify it to get rid of that problem.
    Bradley Miller
    @bnmnetp
    So, here is the problem with the parson’s implementation. For which I feel bad that I was not more clear about way back. parsons.js comes from another github project They are always making improvements to parsons.js and we want to be able to take advantage of that. However in trying to look at the current problem it has become clear that parsons.js has now diverged to the point that it would be very hard. What we really want to do is use the functionality of parsons.js unchanged. We can do this, it just needs a different approach that what we have right now.
    For the moment, I think the right approach is to revert parson’s back to the previous implementation until we can do a new implementation without modifying parsons.js — There are good examples in https://github.com/js-parsons/js-parsons
    Isaiah Mayerchak
    @flysaiah
    Which parts of parsons were changed too much? I thought that I left all of the original code pretty much intact other than reformatting parsons.js to fit our formatting standards, the no-conflict version of jquery, which was causing problems, and the parsons.py code, which couldn't remain the same if we were making our own intermediate HTML. I completely understand the problem with changing too much--I'm just curious about where I went wrong with the first attempt.
    Bradley Miller
    @bnmnetp
    I tried to do a diff on the old parsons.js and the new and there were something like 300+ differences. Maybe most of them were reformatting but even that is hard because now we don’t know what was original code, what was changed to accomadate our coding standards, and what was a real functional change that we might contribute back to the original project. For example, even having parsons extend RunestoneBase is probably too much. We can attach logging in another way.
    Maybe we can just revert parsons.js back to its original state and make the changes to parsonsaux.ps to do what we want.
    Of course we would want to keep all of the changes you made to parsons.py