These are chat archives for supercollider/supercollider

21st
Mar 2017
Nathan Ho
@snappizz
Mar 21 2017 17:18
@brianlheim I know you're busy but I'm waiting on an issue with the LPC regression tests
Brian Heim
@brianlheim
Mar 21 2017 17:19
I just patched the last thing you posted about, is it something else?
also, apparently the ICMC deadline's been extended by a week so :tada:
Nathan Ho
@snappizz
Mar 21 2017 18:29
thanks!
Brian Heim
@brianlheim
Mar 21 2017 18:30
np sorry i didn't catch it earlier
Nathan Ho
@snappizz
Mar 21 2017 18:33
Do you plan to rebase #2751?
After I've gotten it to run and reviewed it, of course
Brian Heim
@brianlheim
Mar 21 2017 18:35
Yeah I definitely don't want to commit all of that to master. Would you be ok with a squash?
Nathan Ho
@snappizz
Mar 21 2017 18:35
yeah
and there's another failure: LID: "unique:Symbol" vs "compile-error"
Brian Heim
@brianlheim
Mar 21 2017 18:35
then i don't have to open a new PR/force-push to my existing branch
Nathan Ho
@snappizz
Mar 21 2017 18:35
in half_3_semanticSuffix_diff
Brian Heim
@brianlheim
Mar 21 2017 18:36
ohhh tricky.. i will have to think about how to resolve that one
Nathan Ho
@snappizz
Mar 21 2017 18:37
Do I have to worry about LID for the other three test suites (lexer targeted brutal, parser brutal, compiler brutal)?
Brian Heim
@brianlheim
Mar 21 2017 18:39
good question...
"LID" can appear as a string in one of the TestLexerTargetedBrutal tests, but it will be properly handled
Nathan Ho
@snappizz
Mar 21 2017 18:40
I'll just run them
Brian Heim
@brianlheim
Mar 21 2017 18:41
the others don't have alphabets that could produce that string
Nathan Ho
@snappizz
Mar 21 2017 18:44
TestLexerTargetedBrutal has failures that seem unrelated to LID. I'll post them in the issue. They're weird as hell.
Brian Heim
@brianlheim
Mar 21 2017 18:44
if you want, you can generate your own output files and send them to me. then i could take care of all the diffs myself without you having to retest/relay them to me each time
uhoh, maybe our machines have different values of pi
Nathan Ho
@snappizz
Mar 21 2017 18:45
Shit
Brian Heim
@brianlheim
Mar 21 2017 18:45
oh hahaha yeah it's some kind of numerical computation error
Screen Shot 2017-03-21 at 2.46.39 PM.png
Nathan Ho
@snappizz
Mar 21 2017 18:48
The LPC tests aren't even done yet and we've found two bugs in sclang
Brian Heim
@brianlheim
Mar 21 2017 18:48
actually, can you tell me the results of these lines:
36r.Q8.high32Bits;
36r.Q8.low32Bits;
Nathan Ho
@snappizz
Mar 21 2017 18:49
1072123651, 689315738
Brian Heim
@brianlheim
Mar 21 2017 18:49
mine gives 1072123651, 689315739
that's a C++/hardware issue I think
i know radix conversion is handled on the spot in PyrLexer.cpp
Nathan Ho
@snappizz
Mar 21 2017 18:50
I think we should ask sc-dev about this
Brian Heim
@brianlheim
Mar 21 2017 18:52
eh, if you want to
i found the call, it's an invocation of pow from the standard header
so I might get a different result if I compiled with different headers even
Brian Heim
@brianlheim
Mar 21 2017 18:57
er actually duh it's division of two doubles after calling pow.
but yeah write to sc-dev and see what people say
if you want the relevant code i can give that to you
double sc_strtof(const char *str, int n, int base)
{
    double z = 0.;
    int decptpos = 0;
    for (int i=0; i<n; ++i)
    {
        int c = *str++;
        if (!c) break;
        if (c >= '0' && c <= '0' + sc_min(10,base) - 1) z = z * base + c - '0';
        else if (c >= 'a' && c <= 'a' + sc_min(36,base) - 11) z = z * base + c - 'a' + 10;
        else if (c >= 'A' && c <= 'A' + sc_min(36,base) - 11) z = z * base + c - 'A' + 10;
        else if (c == '.') decptpos = i;
    }
    //calculation previously included decimal point in count of columns (was n-decptpos); there are 1 less than n characters which are columns in the number contribution
    z = z / pow((double)base, n -1- decptpos);
    return z;
}
Nathan Ho
@snappizz
Mar 21 2017 19:09
No failures in TestParserBrutal :)
Brian Heim
@brianlheim
Mar 21 2017 19:24
woo
ok i think i figured out how i'm gonna deal w all this
doOutputsMatch is just going to return true if the input test string contains "LID"
and it will also do equalWithPrecision for floats
and there will also be a 'strict validation' value that you can set to turn all of that off
because i'm also curious to see what my Windows/Ubuntu machine will say about the floating point stuff
i'm at work now but will do this later
Nathan Ho
@snappizz
Mar 21 2017 20:44
TestCompilerBrutal seems to be stuck on Meta_LPCTestUtils:safeOpenFile: Reading from file: infix_1_basicTCO_correct. How long did that test take for you?
Brian Heim
@brianlheim
Mar 21 2017 20:48
that should be a super quick test
like, under 100 strings total tested
Nathan Ho
@snappizz
Mar 21 2017 20:48
ok, it's not "stuck." it just... ends
it doesn't do any more tests and doesn't report that the tests passed, etc
i'm guessing that silent-sc is suppressing something
Brian Heim
@brianlheim
Mar 21 2017 20:50
yeah it must be. you could run the compiler tests in normal SC, the output should be manageable if it's erroring right after that
Nathan Ho
@snappizz
Mar 21 2017 20:52
nothing in normal SC either
Brian Heim
@brianlheim
Mar 21 2017 20:52
dafuq
ok you know what, I'm just gonna get this running on my ubuntu machine myself
i feel bad that you've run into so many issues; i thought this would be a lot cleaner
Nathan Ho
@snappizz
Mar 21 2017 20:53
i'm also going to try to debug it on my end, since I'm supposed to understand your code anyway
Brian Heim
@brianlheim
Mar 21 2017 20:54
ok! what is strange to me about this is that TestParserBrutal uses the same subroutine (runTestsTogglingTCO)
and it sounds like TestCompilerBrutal is failing right in the middle of that
Nathan Ho
@snappizz
Mar 21 2017 20:55
it does write to the file compiler/infix_1_basicTCO
and the output file is the same length as the corresponding _correct entry. so it's not failing in the middle of the test
Brian Heim
@brianlheim
Mar 21 2017 20:58
ugh i wonder if i have more code that accidentally eats up error messages
Nathan Ho
@snappizz
Mar 21 2017 20:59
I've narrowed it down to the call to this.runTestsOnAlphabet(prefix, suffix, testMode++"TCO", alphabetName); in runTestsTogglingTCO
this.makingValidationFiles appears to be false
but LPCTestUtils.evaluateAllStrings succeeds
narrowed down to LPCTestUtils.compareFiles
Brian Heim
@brianlheim
Mar 21 2017 21:04
oh great...
god i seriously need to factor that method
Nathan Ho
@snappizz
Mar 21 2017 21:05
it's parseHeader
Brian Heim
@brianlheim
Mar 21 2017 21:06
shit i know what it is now
the alphabet line in that file is 2508 characters long
so maxline should be increased to 4096
or i could write an iterative getline
i should have been doing end of line checking in the first place
Nathan Ho
@snappizz
Mar 21 2017 21:08
that appears to fix it
Brian Heim
@brianlheim
Mar 21 2017 21:08
although it doesn't really seem like there's a surefire way to detect whether or not the end of the line was reached in the first place
i actually had this issue before... i decreased it to 512 to see if i could get a performance boost that way and it ended up hanging the same way on a different file
so i was just lazy and didn't put guardrails in even though i knew about the issue. sorry :/
also, I originally was thinking about the data lines, not the header, when I added the maxline parameter
i expected those line sizes to dominate
but then it turned out even 0!99 didn't produce that long of a string
Nathan Ho
@snappizz
Mar 21 2017 21:12
LID-related diff found in TestCompilerBrutal
LID: "0000F2" vs "compile-error"
other than that, all clear!
Brian Heim
@brianlheim
Mar 21 2017 21:13
OK yes I definitely have to make that fix i talked about earlier based on the input string and not the outputs
great!
but also I didn't expect "a LID b" to compile?
oh wait nvm
duh i forgot this is storing bytecodes and not object strings/classes