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
    The details are very hazy, but I think once you have a node you can get access to its children.
    Isaiah Mayerchak
    @flysaiah
    Ok. I'll tinker around with it and see what I can do.
    Bradley Miller
    @bnmnetp
    Or you could create a role like the textarea role that you would use to surround an element that you want to be clickable kind of like what you are doing now, but more tricky, rather than adding an attribute. So I think you have two ways to go.
    Isaiah Mayerchak
    @flysaiah
    So, with the first way, are you suggesting that somewhere during the nested_parse process we could grab all of the nodes that it is parsing and modify them?
    Bradley Miller
    @bnmnetp
    I think that would happen during the visit_xxxx_node call not during parsing.
    For the second, The idea is that during visit_xxx_node you can create the opening tag. and then during depart_xxx_node you create the closing tag
    You might experiment by printing self.body in both the visit and the depart to see what you have available there too.
    Isaiah Mayerchak
    @flysaiah
    Yes--the second way I think I understand, it would pretty much be what I'm doing now, which is wrapping the clickable element in a span, but that would be a problem when it comes to images because of my CSS rules. I think the first way would probably be cleaner, too, it's just I'm not sure how exactly I'd do it. I'll do those print statements.
    Bradley Miller
    @bnmnetp
    The css can be adjusted to not apply to images.
    Isaiah Mayerchak
    @flysaiah
    You're right. The first way has yielded nothing but complications and errors so far, so I'll try wrapping it.
    Isaiah Mayerchak
    @flysaiah
    This message was deleted

    @bnmnetp I'm getting some strange behavior out of self.state.nested_parse() when the directive has content that isn't composed solely out of other directives (i.e. text). The content is getting parsed twice--for example, in the RST

    .. clickablearea:: click1
        :question: Click on all assignment statements.
        :feedback: Remember, the operator '=' is used for assignment.
    
        :click-incorrect:def main()::endclick:
            :click-correct:x = 4:endclick:
            for i in range(5):
                :click-correct:y = i:endclick:
                :click-incorrect:if y > 2::endclick:
                    print(y)

    , the code block starting with :click-incorrect: is getting rendered once normally, then once again after the full component has been rendered like this:

    <dl class="docutils">
    <dt>:click-incorrect:def main()::endclick:</dt>
    <dd><p class="first">:click-correct:x = 4:endclick:
    for i in range(5):</p>
    <blockquote class="last">
    <div><p>:click-correct:y = i:endclick:
    :click-incorrect:if y &gt; 2::endclick:</p>
    <blockquote>
    <div>print(y)</div></blockquote>
    </div></blockquote>
    </dd>
    </dl>

    Do you know why this is happening? It's a big roadblock and I'm unsure of what to do about it.

    Isaiah Mayerchak
    @flysaiah
    Edit: It's not rendering twice anymore, but it's still rendering as a weird <dl class-docutils> element.
    Bradley Miller
    @bnmnetp
    I haven’t run into that before. If you can’t figure it out, there is an irc channel and a forum for sphinx/rst development.
    Isaiah Mayerchak
    @flysaiah
    I think it's because there's never been an occasion to use a nested parse for a container directivd that held both other directives AND text as content. I'll check out the channel/forum.
    Bradley Miller
    @bnmnetp
    its exactly what reveal does right?
    Isaiah Mayerchak
    @flysaiah
    That's a very good point--I'll check what I'm doing differently between the two components to find out what's going wrong.
    Kirby Olson
    @riknos314
    Trying to combine the javascript files with google closure compiler hasn't been very fruitful. After modifying many of the files (getting rid of trailing commas) to stop the linter from throwing errors so that I could actually compile, the file that I get back doesn't work. I tried setting the compiler to the 'whitespace_only' setting so that it wouldn't minify variable names, and that still doesn't work. It appears to cause the various versions of jquery that we have to not play well with each other as I'm continually running into errors with $(...).method() is not a function where method is any number of different methods. I'll try a couple other methods and see if anything works.
    Bradley Miller
    @bnmnetp
    Are you trying to include the jquery instances in with the final file or are you leaving them separate?
    Kirby Olson
    @riknos314
    I've been trying to include all the js in the _static directory in the order that they appear in the head of the test page (which works flawlessly).
    I guess that I could experiment with making a few, smaller bundles. I just really don't want to mess with the order that things are loaded in because that has proven to be quite fragile in my experience.
    Bradley Miller
    @bnmnetp
    You could also start with the super simple approach of just using that order and then either manually or with cat combine them without any compression or additional messing around.
    Kirby Olson
    @riknos314
    I just tried concatenating the files at your suggestion, and I'm getting the exact same problems. Just to be sure that I didn't mess up the concatenation I grepped through the combined file and the methods are indeed defined. Maybe the files are parsed differently as individual files? I'll do some research.
    Isaiah Mayerchak
    @flysaiah
    I'm running into problem after problem with trying to wrap things inside click-correct or click-incorrect elements in rST for clickablearea, and I'm becoming increasingly doubtful about the possibility of it working at all, so I came up with another solution. In the case of having a number of images or a table, in the option spec of clickablearea the user can specify the indices of the images they would like to be correct, and the indices of the images they would like to be incorrect--much like what we do with multiple choice multiple answer. For example, if the user has 5 images inside the clickablearea directive they can list images 2, 3, and 5 as being correct and 1,4 as being incorrect. In a table, each data cell would be one index. If all they have is text, they can specify that with :iscode: and still wrap whatever they want in click-correct and click-incorrect wrappers--the index method will only be for images/tables/etc, so the old functionality is still preserved. The only limitation this has is that people won't be able to make both images and plain text (that isn't in a table) clickable in the same element (they can't use both indices AND wrappers), but I don't think that's something that would be very popular to do in the first place. Does this sound reasonable?
    Bradley Miller
    @bnmnetp
    The generated html element would have the correct or incorrect as an attribute then?
    Isaiah Mayerchak
    @flysaiah
    In the old case, everything would work as it has, so yes. In the new images/table case, the html wouldn't have the data-correct or data-incorrect attribute but I can add a data-correctElements and data-incorrectElements to the clickablearea component and add a function in our javascript that will parse those and the rest of the component will behave the same.
    It will be a feature that's really only for the Sphinx-rST parsing, but I've been running into a brick wall with doing this in Sphinx whereas I know this will work in the JS.
    Bradley Miller
    @bnmnetp
    OK, then.
    Bradley Miller
    @bnmnetp
    Hi guys, I built our CS1 book using all of the new directives that have been submitted as PRs. I have been uncovering some bugs and have filed those as Issues.
    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