Comments for happiest unalice ever http://alice.nodelman.net/blog infrequent updates and long delays Thu, 09 Sep 2010 01:00:04 +0000 http://wordpress.org/?v=2.7 hourly 1 Comment on Universal Manifest For Unit Tests: A Proposal by improving personal hygiene by adjusting mochitests « 3.1415926535897932384626433… http://alice.nodelman.net/blog/post/universal-manifest-for-unit-tests-a-proposal/comment-page-1/#comment-16945 improving personal hygiene by adjusting mochitests « 3.1415926535897932384626433… Mon, 05 Jul 2010 21:48:24 +0000 http://alice.nodelman.net/blog/?p=110#comment-16945 [...] have other great formats available and there has been great discussion around this topic in other blog posts.  In general the consensus is keeping something like the reftest manifest format and extending it [...] [...] have other great formats available and there has been great discussion around this topic in other blog posts.  In general the consensus is keeping something like the reftest manifest format and extending it [...]

]]> Comment on Universal Manifest For Unit Tests: A Proposal by Ms2ger http://alice.nodelman.net/blog/post/universal-manifest-for-unit-tests-a-proposal/comment-page-1/#comment-16411 Ms2ger Fri, 04 Jun 2010 11:01:21 +0000 http://alice.nodelman.net/blog/?p=110#comment-16411 I think the examples in this post make it clear that JSON is not easy enough to use. JSON doesn't allow quoting strings with single quotes ('), which means none of these ten examples can actually be parsed. Also, the duplicate attributes in #2, #3 and #10 cause information to be lost silently. I think the examples in this post make it clear that JSON is not easy enough to use. JSON doesn’t allow quoting strings with single quotes (’), which means none of these ten examples can actually be parsed. Also, the duplicate attributes in #2, #3 and #10 cause information to be lost silently.

]]> Comment on Universal Manifest For Unit Tests: A Proposal by Robert Kaiser http://alice.nodelman.net/blog/post/universal-manifest-for-unit-tests-a-proposal/comment-page-1/#comment-16405 Robert Kaiser Thu, 03 Jun 2010 20:24:03 +0000 http://alice.nodelman.net/blog/?p=110#comment-16405 So, this loses all the info in comments, right? Can there be made something to keep the comments in some way, perhaps as a field in the JSON as the format itself sucks in not allowing real comments? Also, in case 2, why have two "fails" entries with one "if" each, and not have one "fails" with two "if"s? And what about using pref values/comparisons in "if" clauses? So, this loses all the info in comments, right? Can there be made something to keep the comments in some way, perhaps as a field in the JSON as the format itself sucks in not allowing real comments?

Also, in case 2, why have two “fails” entries with one “if” each, and not have one “fails” with two “if”s?

And what about using pref values/comparisons in “if” clauses?

]]> Comment on Universal Manifest For Unit Tests: A Proposal by Jesse Ruderman http://alice.nodelman.net/blog/post/universal-manifest-for-unit-tests-a-proposal/comment-page-1/#comment-16404 Jesse Ruderman Thu, 03 Jun 2010 19:57:45 +0000 http://alice.nodelman.net/blog/?p=110#comment-16404 I still see no benefit to replacing the simple existing reftest format with JSON, and a lot of drawbacks. All of the benefits you've claimed for moving to JSON have been orthogonal to the overall syntax, and something we could get with much smaller changes. I don't understand why you continue pushing for moving to JSON when it seems obvious to me that making small changes to the reftest manifest format would result in a format that's much easier to use. Btw, #1 and #2 use duplicate attributes. I think you'd need to use JSON arrays rather than JSON hashes in a few spots. I still see no benefit to replacing the simple existing reftest format with JSON, and a lot of drawbacks. All of the benefits you’ve claimed for moving to JSON have been orthogonal to the overall syntax, and something we could get with much smaller changes. I don’t understand why you continue pushing for moving to JSON when it seems obvious to me that making small changes to the reftest manifest format would result in a format that’s much easier to use.

Btw, #1 and #2 use duplicate attributes. I think you’d need to use JSON arrays rather than JSON hashes in a few spots.

]]> Comment on Universal Manifest Format For Unit Tests (part 2) by Robert Kaiser http://alice.nodelman.net/blog/post/universal-manifest-format-for-unit-tests-part-2/comment-page-1/#comment-16140 Robert Kaiser Wed, 19 May 2010 16:18:37 +0000 http://alice.nodelman.net/blog/?p=92#comment-16140 What would be really good is to have some possibility to say "if the pref foo is (not) true/2/'bar'" in the skip-if or random-if values. Reftests can currently do that, and we have somewhat strangely done things in other tests for that, like bailing out early from a test when a pref is (not) matched. It would be nice to have a generic way to set this. What would be really good is to have some possibility to say “if the pref foo is (not) true/2/’bar’” in the skip-if or random-if values.
Reftests can currently do that, and we have somewhat strangely done things in other tests for that, like bailing out early from a test when a pref is (not) matched. It would be nice to have a generic way to set this.

]]> Comment on Universal Manifest Format For Unit Tests (part 2) by David Baron http://alice.nodelman.net/blog/post/universal-manifest-format-for-unit-tests-part-2/comment-page-1/#comment-16062 David Baron Sun, 16 May 2010 22:17:34 +0000 http://alice.nodelman.net/blog/?p=92#comment-16062 I think the skip, fails, etc. conditions should remain JS. That keeps it clear what's an && vs. an ||. We can use significantly shorter variable names (the current MOZ_WIDGET_TOOLKIT is for backwards compatibility). However, I'm wary of making them too short. Currently things are based on widget because that's the most likely cause of platform-specific failures in reftests, which mostly test layout and graphics. But if we start using this for other tests, that will likely change. And once we have a qt build (for mobile) there's a real difference between "this fails with gtk widgets" and "this fails on Linux". I'd prefer something like: fails: true or fails: widget == "cocoa" I think the skip, fails, etc. conditions should remain JS. That keeps it clear what’s an && vs. an ||.

We can use significantly shorter variable names (the current MOZ_WIDGET_TOOLKIT is for backwards compatibility). However, I’m wary of making them too short. Currently things are based on widget because that’s the most likely cause of platform-specific failures in reftests, which mostly test layout and graphics. But if we start using this for other tests, that will likely change. And once we have a qt build (for mobile) there’s a real difference between “this fails with gtk widgets” and “this fails on Linux”.

I’d prefer something like:
fails: true
or
fails: widget == “cocoa”

]]> Comment on Universal Manifest Format For Unit Tests (part 2) by alice http://alice.nodelman.net/blog/post/universal-manifest-format-for-unit-tests-part-2/comment-page-1/#comment-16027 alice Sat, 15 May 2010 20:22:55 +0000 http://alice.nodelman.net/blog/?p=92#comment-16027 @Boris - the indentation is not required by json, I've included it in the examples to make things more readable. @Boris - the indentation is not required by json, I’ve included it in the examples to make things more readable.

]]> Comment on Universal Manifest Format For Unit Tests (part 2) by Rob Sayre http://alice.nodelman.net/blog/post/universal-manifest-format-for-unit-tests-part-2/comment-page-1/#comment-16018 Rob Sayre Sat, 15 May 2010 14:42:29 +0000 http://alice.nodelman.net/blog/?p=92#comment-16018 I like this plan. YAML is nicer for humans to write than JSON, has plenty of parser support, and it has comments. I would go with that instead. I like this plan. YAML is nicer for humans to write than JSON, has plenty of parser support, and it has comments. I would go with that instead.

]]> Comment on Universal Manifest Format For Unit Tests (part 2) by Robert O'Callahan http://alice.nodelman.net/blog/post/universal-manifest-format-for-unit-tests-part-2/comment-page-1/#comment-16013 Robert O'Callahan Sat, 15 May 2010 11:41:56 +0000 http://alice.nodelman.net/blog/?p=92#comment-16013 How about replacing the token 'files' with the type, use an extended JSON that allows the value to be an array and allows comments, and don't indent array elements, so one could write [ {"==": ["file1.html", "file1-ref.html"]}, {"==": ["file2.html", "file2-ref.html"]}, // {"==": ["file3.html", "file3-ref.html"]}, {"==": ["file4.html", "file4-ref.html"]}, ] This would keep common cases on one line without indentation, which I think would be a big help. How about replacing the token ‘files’ with the type, use an extended JSON that allows the value to be an array and allows comments, and don’t indent array elements, so one could write

[
{"==": ["file1.html", "file1-ref.html"]},
{”==”: ["file2.html", "file2-ref.html"]},
// {”==”: ["file3.html", "file3-ref.html"]},
{”==”: ["file4.html", "file4-ref.html"]},
]

This would keep common cases on one line without indentation, which I think would be a big help.

]]> Comment on Universal Manifest Format For Unit Tests (part 2) by Boris http://alice.nodelman.net/blog/post/universal-manifest-format-for-unit-tests-part-2/comment-page-1/#comment-16000 Boris Sat, 15 May 2010 02:23:21 +0000 http://alice.nodelman.net/blog/?p=92#comment-16000 So for the common case this is a lot more typing than the current reftest format, actually. Worse yet, there's indentation involved, which can very easily get pretty wacky unless one is careful (which increases the time it takes to add entries even more). Do we have any plan for handling that? So for the common case this is a lot more typing than the current reftest format, actually. Worse yet, there’s indentation involved, which can very easily get pretty wacky unless one is careful (which increases the time it takes to add entries even more). Do we have any plan for handling that?

]]>