https://groups.google.com/forum/#!topic/julia-users/5EkY__AV0m4 is potentially relevant since changing the way this works could help give context for each variable in the expressions that the macro sees, making it easier to figure out what to print the value of and what not to.
On Thu, Feb 20, 2014 at 7:38 AM, Stefan Karpinski < [email protected]> wrote: > The approach that I've mulled over but not gotten around to implementing > is to print the failed assertion expression as we do now but then print the > bindings of all the variables in that expression. It would probably be > sufficient to print the values of bindings that are not global and > constant. If we introduced anonymous modules to evaluate each test file – > also a good idea – then it would probably suffice to print the bindings of > locals and globals in that module. > > On Feb 20, 2014, at 6:46 AM, andrew cooke <[email protected]> wrote: > > I did wonder about making assert_eq, but was less offended by [!!=] (the > square brackets are there to indicate that this is not to be taken > literally) - it seemed worth the flexibility. Also, I am still feeling my > way around the macro syntax - it seems like optional args have to be > handled by counting "..." parameters? > > I do agree on "as much info as possible". It seems like you could do both > - have both the expression and the result. Perhaps in a nice table or on > multiple lines. > > When I am stuck on my current project I will give it another go. > > Cheers, Andrew > > On Thursday, 20 February 2014 06:11:15 UTC-3, Ivar Nesje wrote: >> >> The testing/assertion API in julia could definitely need some love. Your >> function does not match my idea of an assertion, because you assume that I >> always use == or === as the operator. Sometimes I might write `@assert >> length(a) != 0`, and then your output will be `ERROR: Assertion failed: 0 >> [!!=] 0`, which is not more informative in my opinion. >> >> Maybe your functionality fits better a `@test_eq` / `@assert_eq` macro, >> with a optional == as the middle argument, that both provides the >> expression and the values? >> >> s = State(0x752878397493CB70) >> @test_eq encrypt(s, 0x1122334455667788) 0xB5219EE81AA7499D >> ## or >> @test_eq encrypt(s, 0x1122334455667788) == 0xB5219EE81AA7499D >> >> >> ERROR: Test failed: >> encrypt(s, 0x1122334455667788) != 0xB5219EE81AA7499D >> 8721fdc137e0d2c0 != b5219ee81aa7499d >> >> I can not see when you want only the values that failed comparison, and >> not the expression that provided the values. When something fails, I >> usually wants the maximum information available. >> >> Regards >> Ivar >> >> kl. 00:20:08 UTC+1 torsdag 20. februar 2014 skrev andrew cooke følgende: >>> >>> Looking at it, I don't see why you couldn't evaluate the left and right >>> halves once, befre the comparison, to save duplicating work. But I have >>> bugs to fix... >>> >>> >>> On Wednesday, 19 February 2014 19:51:02 UTC-3, andrew cooke wrote: >>>> >>>> Hi, >>>> >>>> Posting in case: (1) others find this useful; (2) to seek feedback on >>>> code (still wandering around in the dark a little); (3) to find out if >>>> similar already exists. >>>> >>>> These are a couple of macros that are like @assert, but which print out >>>> the actual values, instead of the expression. >>>> >>>> So, for example, I have some code like: >>>> >>>> # http://cryptomanager.com/tv.html >>>> >>>> s = State(0x752878397493CB70) >>>> @assert3f hex encrypt(s, 0x1122334455667788) == 0xB5219EE81AA7499D >>>> >>>> which produces output: >>>> >>>> ERROR: Assertion failed: 8721fdc137e0d2c0 [!==] b5219ee81aa7499d >>>> >>>> (which is much more useful, IMHO). >>>> >>>> Code is at https://github.com/andrewcooke/BlockCipherSelfStudy.jl/blob/ >>>> master/src/Assert.jl but you'll need to cut + paste as it's part of a >>>> larger package not intended for public use. >>>> >>>> Cheers, >>>> Andrew >>>> >>>> >>>>
