convore.json/groups/arc-runtime-project/python-style-doctest-library/messages.json

[{"user_id": 32737, "stars": [], "topic_id": 34832, "date_created": 1305148998.9943781, "message": "Okay, so, I wrote a small library that implements Python style doctests. I'll be using it as much as I can for the tests that I personally write, and will probably convert the existing tests (at least the ones for Arc) over to it as well.", "group_id": 9739, "id": 1014678}, {"user_id": 32737, "stars": [], "topic_id": 34832, "date_created": 1305149138.205317, "message": "There are a few benefits to this approach:", "group_id": 9739, "id": 1014704}, {"user_id": 32737, "stars": [], "topic_id": 34832, "date_created": 1305149342.2524669, "message": "3) Because it's using regular expressions to munge the text, it should be pretty easy to get nice information, like line numbers, which is more difficult if you're parsing the entire thing. Hopefully this won't be a big deal later on, when ar can actually display line numbers, but right now this is an advantage.", "group_id": 9739, "id": 1014741}, {"user_id": 32737, "stars": [], "topic_id": 34832, "date_created": 1305149121.5828781, "message": "How it works is pretty simple: it looks for \" *>>> \" and then reads a single Arc expression. This expression will be eval'd by Arc. It then looks for all the non-blank lines following the expression. This will be the expected output. It then compares the input to the output, and if they don't match, it'll print out some nicely formatted failure information.", "group_id": 9739, "id": 1014701}, {"user_id": 32737, "stars": [], "topic_id": 34832, "date_created": 1305149182.736861, "message": "1) I think it looks nicer, than using macros.", "group_id": 9739, "id": 1014715}, {"user_id": 32737, "stars": [], "topic_id": 34832, "date_created": 1305149442.081181, "message": "Anyways, I'm going to put it into \"lib/tester.arc\", along with \"lib/re.arc\", which it uses to do the actual munging. I also put in a \"run-tests\" file and \"tests/(coerce foo 'fn)\", which tests that coercing to a function works correctly.", "group_id": 9739, "id": 1014762}, {"user_id": 32737, "stars": [], "topic_id": 34832, "date_created": 1305149254.3584411, "message": "2) It only evaluates stuff following \">>> \", which means you can include text/prose/documentation right next to the tests. I take advantage of this in my tests for `multi-string-filter`", "group_id": 9739, "id": 1014727}, {"user_id": 25438, "stars": [], "topic_id": 34832, "date_created": 1305151176.3014359, "message": "I have a vague far-future plan to integrate unit tests into eval.to examples.  Which isn't to say we shouldn't do something *now* that's actually working, just an fyi.", "group_id": 9739, "id": 1015242}, {"user_id": 32737, "stars": [], "topic_id": 34832, "date_created": 1305151265.8024271, "message": "Okay, but why not use Python style doctests for that? :P Then when it sees >>> in the text, it'll treat it as a runnable example.", "group_id": 9739, "id": 1015271}, {"user_id": 32737, "stars": [], "topic_id": 34832, "date_created": 1305151757.110791, "message": "By the way, the re.arc library I'm using is amazing, and I love it's design, but it has some pretty annoying bugs in it. It can't do look-ahead for instance, and it doesn't handle the * special character correctly. We should fix those bugs at some point, but I managed to work around them in tester.arc.", "group_id": 9739, "id": 1015356}, {"user_id": 32737, "stars": [], "topic_id": 34832, "date_created": 1305151669.5904591, "message": "Ah, I see, that makes sense.", "group_id": 9739, "id": 1015338}, {"user_id": 25438, "stars": [], "topic_id": 34832, "date_created": 1305152759.885381, "message": "It'd be interesting to compare with my match library sometime.", "group_id": 9739, "id": 1015607}, {"user_id": 25438, "stars": [], "topic_id": 34832, "date_created": 1305151612.869725, "message": "I embed the example in the documentation because that lets me attach lots of extra information to the example such as which operating system it ran on, which variant of Arc exactly was being used, what source code the example actually used, etc.  Though we certainly could have a parser that looked for \">>>\" and used that as a super-convenient way to create examples.", "group_id": 9739, "id": 1015326}, {"user_id": 32737, "stars": [], "topic_id": 34832, "date_created": 1305152590.43841, "message": "No, it's from here: http://www.lisperati.com/arc/regex.html", "group_id": 9739, "id": 1015556}, {"user_id": 25438, "stars": [], "topic_id": 34832, "date_created": 1305152315.4750581, "message": "re.arc from Anarki?", "group_id": 9739, "id": 1015449}, {"user_id": 32737, "stars": [], "topic_id": 34832, "date_created": 1305152695.8746569, "message": "I like the way it's designed, it doesn't seem to follow the usual route that other languages use with regular expressions. It just feels ... well, nice. It feels Arc-y to me. I've used regular expressions quite a bit with JS, but I like that library a lot better. If only it didn't have those bugs...", "group_id": 9739, "id": 1015592}]