{"payload":{"feedbackUrl":"https://github.com/orgs/community/discussions/53140","repo":{"id":589920852,"defaultBranch":"main","name":"mmpio","ownerLogin":"FINNGEN","currentUserCanPush":false,"isFork":false,"isEmpty":false,"createdAt":"2023-01-17T08:56:16.000Z","ownerAvatar":"https://avatars.githubusercontent.com/u/33527341?v=4","public":true,"private":false,"isOrgOwned":true},"refInfo":{"name":"","listCacheKey":"v0:1707213851.0","currentOid":""},"activityList":{"items":[{"before":"7c2ea4f74e03394c6a1a8e64bb7d792f6b302216","after":"260ca641162b8606ff80fcbe6dac5b4f02123fa2","ref":"refs/heads/main","pushedAt":"2024-02-06T11:50:26.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"vincent-octo","name":"vincent","path":"/vincent-octo","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/4919840?s=80&v=4"},"commit":{"message":"add automatic end-to-end tests\n\nThere were no automatic tests for mmpio, making it difficult to find\nregression, trust the system, or do refactoring.\n\nIn this commit I add 2 simple end-to-end tests that are automatically\nrun on GitHub Actions. This makes a nice base for adding other tests in\nthe future.\n\nI didn't find a simple way to have:\n- end-to-end tests run with `go test`\n- plain text file for dummy data\nAs this would require refactoring the Go code to allow uncompressed\ninput files. Even though it would have been fun to use go embeds. >:)\n\nDuring this, I discovered that having our CLI flag setup in the init()\nfunction was problematic as it made `go test` error out without reason.\nI solved this by calling the flag parser in main() instead of init().\nMore information here:\nhttps://go.dev/doc/go1.13#testingpkgtesting","shortMessageHtmlLink":"add automatic end-to-end tests"}},{"before":"27dd6d9d118f0f59764d8e6644dbc144f904e81a","after":"4de6117e51e11443263c122904002ea010245f21","ref":"refs/heads/push-nusrmwpwlzsk","pushedAt":"2024-02-06T11:37:49.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"vincent-octo","name":"vincent","path":"/vincent-octo","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/4919840?s=80&v=4"},"commit":{"message":"add testing\n\nProblem: there is currently no automatic tests for mmpio, making it\ndifficult to find regression, trust the system, do refactoring.\n\nWhat I am about to do: think what kind of tests I want (i.e. what will\nthe tests cover), implement them, make sure they are automatic and\ntheir status is in a tight feedback loop.\n\nWhat I expect the result to be: implemented a couple of tests (not\ncovering the whole codebase, but at least enough so that for the next\nchange I can write a test with the same system); integrated in GitHub\nactions with clear status.\n\n\n* 2024-02-02  Let's start simple\nWhat would be the simplest test?\nMaybe one where we have 2 rows as input, and just get 1 in the output\nwith the p-value < 1e-6.\n\nI could use go embeds to have input & output files as plain text files,\nbut make easier (?), slicker (?) to deal with in Go code.\nNot sure if good long-term decision, but looks fun! Hype!\n\nOK, starting with making a dummy test to understand how `go test` work\nand get going.\n\nSeems `go test` is looking for *_test.go files.\n\nErr, seems there is some (bad) interactions between the flags package\nand testing?\n\nBy injecting a `fmt.Println(os.Args)` I can see that the program is\ncalled with:\n.../mmpio.test -test.paniconexit0 -test.timeout=10m0s\n\nRemoving the custom Usage function doesn't remove the error.\n\nRead about the interaction between init() and flag and testing at:\nhttps://go.dev/doc/go1.13#testingpkgtesting\n\nFixed go test run bug by changing my code to init the flag in main()\ninstead of init().\n\nNow basic dummy test is working as expected.\n\n\n* 2024-02-06\nChecking status. I should be able to run `go test` and have the dummy\ntest PASS or FAIL.\nWorking as expected.\n\nNow turning that into a real test.\nMaking the dummy data first.\n\nHmm, sum stats are expected to be gzip-compressed.\nLet's see.\n\nArh. I don't want to put gzipped data files in Git.\nIt will just make it harder to simply read and write.\n\nWhat are my options:\n1. embed the tsv file, then gzip it during test\n2. refactor the main mmpio funcs to allow a compression argument\n3. refactor to specify the compression in config file\n\nOption (1.) seems the best since we won't benefit from the refactoring\noptions elsewhere.\nBut is it possible? Our current process is that we provide a filepath,\nnot a gzip buffer.\n\nCan we have a 4th option where we bypass the conf?\nWe could make a conf struct in the test.\nBut still need to provide a filepath as `string` to streamTsv.\n\nA 5th option would be to use something else than go test, just bash.\nMaybe the best option for end-to-end test.\nWhile `go test` would be good for unit tests.\n\nLet's see how this 5th option would work.\nWould need to access an mmpio binary?\nOr just with go run maybe.\n\"The exit status of Run is not the exit status of the compiled binary.\"\nHmm.\n\nOtherwise I can add a build step in the test.sh, but then how to turn\nthe test TSV into a GZIP and inject the path somehow in the conf file?\n\nSo we can just do option 5, and provide the gzip path in the conf and\nmake this gzip file on test run.\n\nGH actions fails because the test action doesn't have a build step\nso our test script cannot find a ./mmpio to run.\n\nTest working as expected on GH actions! :tada:\n\n\nNow onto second test, and refactor a little the common bash bits.","shortMessageHtmlLink":"add testing"}},{"before":"d020dd44420fa38ea274a1ec13142e20003bdd24","after":"27dd6d9d118f0f59764d8e6644dbc144f904e81a","ref":"refs/heads/push-nusrmwpwlzsk","pushedAt":"2024-02-06T11:35:34.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"vincent-octo","name":"vincent","path":"/vincent-octo","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/4919840?s=80&v=4"},"commit":{"message":"add testing\n\nProblem: there is currently no automatic tests for mmpio, making it\ndifficult to find regression, trust the system, do refactoring.\n\nWhat I am about to do: think what kind of tests I want (i.e. what will\nthe tests cover), implement them, make sure they are automatic and\ntheir status is in a tight feedback loop.\n\nWhat I expect the result to be: implemented a couple of tests (not\ncovering the whole codebase, but at least enough so that for the next\nchange I can write a test with the same system); integrated in GitHub\nactions with clear status.\n\n\n* 2024-02-02  Let's start simple\nWhat would be the simplest test?\nMaybe one where we have 2 rows as input, and just get 1 in the output\nwith the p-value < 1e-6.\n\nI could use go embeds to have input & output files as plain text files,\nbut make easier (?), slicker (?) to deal with in Go code.\nNot sure if good long-term decision, but looks fun! Hype!\n\nOK, starting with making a dummy test to understand how `go test` work\nand get going.\n\nSeems `go test` is looking for *_test.go files.\n\nErr, seems there is some (bad) interactions between the flags package\nand testing?\n\nBy injecting a `fmt.Println(os.Args)` I can see that the program is\ncalled with:\n.../mmpio.test -test.paniconexit0 -test.timeout=10m0s\n\nRemoving the custom Usage function doesn't remove the error.\n\nRead about the interaction between init() and flag and testing at:\nhttps://go.dev/doc/go1.13#testingpkgtesting\n\nFixed go test run bug by changing my code to init the flag in main()\ninstead of init().\n\nNow basic dummy test is working as expected.\n\n\n* 2024-02-06\nChecking status. I should be able to run `go test` and have the dummy\ntest PASS or FAIL.\nWorking as expected.\n\nNow turning that into a real test.\nMaking the dummy data first.\n\nHmm, sum stats are expected to be gzip-compressed.\nLet's see.\n\nArh. I don't want to put gzipped data files in Git.\nIt will just make it harder to simply read and write.\n\nWhat are my options:\n1. embed the tsv file, then gzip it during test\n2. refactor the main mmpio funcs to allow a compression argument\n3. refactor to specify the compression in config file\n\nOption (1.) seems the best since we won't benefit from the refactoring\noptions elsewhere.\nBut is it possible? Our current process is that we provide a filepath,\nnot a gzip buffer.\n\nCan we have a 4th option where we bypass the conf?\nWe could make a conf struct in the test.\nBut still need to provide a filepath as `string` to streamTsv.\n\nA 5th option would be to use something else than go test, just bash.\nMaybe the best option for end-to-end test.\nWhile `go test` would be good for unit tests.\n\nLet's see how this 5th option would work.\nWould need to access an mmpio binary?\nOr just with go run maybe.\n\"The exit status of Run is not the exit status of the compiled binary.\"\nHmm.\n\nOtherwise I can add a build step in the test.sh, but then how to turn\nthe test TSV into a GZIP and inject the path somehow in the conf file?\n\nSo we can just do option 5, and provide the gzip path in the conf and\nmake this gzip file on test run.\n\nGH actions fails because the test action doesn't have a build step\nso our test script cannot find a ./mmpio to run.\n\nTest working as expected on GH actions! :tada:\n\n\nNow onto second test, and refactor a little the common bash bits.","shortMessageHtmlLink":"add testing"}},{"before":"3939328ba31508f31a73dba90828e33cbe1e8496","after":"d020dd44420fa38ea274a1ec13142e20003bdd24","ref":"refs/heads/push-nusrmwpwlzsk","pushedAt":"2024-02-06T11:21:59.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"vincent-octo","name":"vincent","path":"/vincent-octo","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/4919840?s=80&v=4"},"commit":{"message":"add testing\n\nProblem: there is currently no automatic tests for mmpio, making it\ndifficult to find regression, trust the system, do refactoring.\n\nWhat I am about to do: think what kind of tests I want (i.e. what will\nthe tests cover), implement them, make sure they are automatic and\ntheir status is in a tight feedback loop.\n\nWhat I expect the result to be: implemented a couple of tests (not\ncovering the whole codebase, but at least enough so that for the next\nchange I can write a test with the same system); integrated in GitHub\nactions with clear status.\n\n\n* 2024-02-02  Let's start simple\nWhat would be the simplest test?\nMaybe one where we have 2 rows as input, and just get 1 in the output\nwith the p-value < 1e-6.\n\nI could use go embeds to have input & output files as plain text files,\nbut make easier (?), slicker (?) to deal with in Go code.\nNot sure if good long-term decision, but looks fun! Hype!\n\nOK, starting with making a dummy test to understand how `go test` work\nand get going.\n\nSeems `go test` is looking for *_test.go files.\n\nErr, seems there is some (bad) interactions between the flags package\nand testing?\n\nBy injecting a `fmt.Println(os.Args)` I can see that the program is\ncalled with:\n.../mmpio.test -test.paniconexit0 -test.timeout=10m0s\n\nRemoving the custom Usage function doesn't remove the error.\n\nRead about the interaction between init() and flag and testing at:\nhttps://go.dev/doc/go1.13#testingpkgtesting\n\nFixed go test run bug by changing my code to init the flag in main()\ninstead of init().\n\nNow basic dummy test is working as expected.\n\n\n* 2024-02-06\nChecking status. I should be able to run `go test` and have the dummy\ntest PASS or FAIL.\nWorking as expected.\n\nNow turning that into a real test.\nMaking the dummy data first.\n\nHmm, sum stats are expected to be gzip-compressed.\nLet's see.\n\nArh. I don't want to put gzipped data files in Git.\nIt will just make it harder to simply read and write.\n\nWhat are my options:\n1. embed the tsv file, then gzip it during test\n2. refactor the main mmpio funcs to allow a compression argument\n3. refactor to specify the compression in config file\n\nOption (1.) seems the best since we won't benefit from the refactoring\noptions elsewhere.\nBut is it possible? Our current process is that we provide a filepath,\nnot a gzip buffer.\n\nCan we have a 4th option where we bypass the conf?\nWe could make a conf struct in the test.\nBut still need to provide a filepath as `string` to streamTsv.\n\nA 5th option would be to use something else than go test, just bash.\nMaybe the best option for end-to-end test.\nWhile `go test` would be good for unit tests.\n\nLet's see how this 5th option would work.\nWould need to access an mmpio binary?\nOr just with go run maybe.\n\"The exit status of Run is not the exit status of the compiled binary.\"\nHmm.\n\nOtherwise I can add a build step in the test.sh, but then how to turn\nthe test TSV into a GZIP and inject the path somehow in the conf file?\n\nSo we can just do option 5, and provide the gzip path in the conf and\nmake this gzip file on test run.\n\nGH actions fails because the test action doesn't have a build step\nso our test script cannot find a ./mmpio to run.\n\nTest working as expected on GH actions! :tada:\n\n\nNow onto second test, and refactor a little the common bash bits.","shortMessageHtmlLink":"add testing"}},{"before":"0aa84386773efc44559d3bf8aafd7f31a5726834","after":"3939328ba31508f31a73dba90828e33cbe1e8496","ref":"refs/heads/push-nusrmwpwlzsk","pushedAt":"2024-02-06T11:20:27.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"vincent-octo","name":"vincent","path":"/vincent-octo","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/4919840?s=80&v=4"},"commit":{"message":"add testing\n\nProblem: there is currently no automatic tests for mmpio, making it\ndifficult to find regression, trust the system, do refactoring.\n\nWhat I am about to do: think what kind of tests I want (i.e. what will\nthe tests cover), implement them, make sure they are automatic and\ntheir status is in a tight feedback loop.\n\nWhat I expect the result to be: implemented a couple of tests (not\ncovering the whole codebase, but at least enough so that for the next\nchange I can write a test with the same system); integrated in GitHub\nactions with clear status.\n\n\n* 2024-02-02  Let's start simple\nWhat would be the simplest test?\nMaybe one where we have 2 rows as input, and just get 1 in the output\nwith the p-value < 1e-6.\n\nI could use go embeds to have input & output files as plain text files,\nbut make easier (?), slicker (?) to deal with in Go code.\nNot sure if good long-term decision, but looks fun! Hype!\n\nOK, starting with making a dummy test to understand how `go test` work\nand get going.\n\nSeems `go test` is looking for *_test.go files.\n\nErr, seems there is some (bad) interactions between the flags package\nand testing?\n\nBy injecting a `fmt.Println(os.Args)` I can see that the program is\ncalled with:\n.../mmpio.test -test.paniconexit0 -test.timeout=10m0s\n\nRemoving the custom Usage function doesn't remove the error.\n\nRead about the interaction between init() and flag and testing at:\nhttps://go.dev/doc/go1.13#testingpkgtesting\n\nFixed go test run bug by changing my code to init the flag in main()\ninstead of init().\n\nNow basic dummy test is working as expected.\n\n\n* 2024-02-06\nChecking status. I should be able to run `go test` and have the dummy\ntest PASS or FAIL.\nWorking as expected.\n\nNow turning that into a real test.\nMaking the dummy data first.\n\nHmm, sum stats are expected to be gzip-compressed.\nLet's see.\n\nArh. I don't want to put gzipped data files in Git.\nIt will just make it harder to simply read and write.\n\nWhat are my options:\n1. embed the tsv file, then gzip it during test\n2. refactor the main mmpio funcs to allow a compression argument\n3. refactor to specify the compression in config file\n\nOption (1.) seems the best since we won't benefit from the refactoring\noptions elsewhere.\nBut is it possible? Our current process is that we provide a filepath,\nnot a gzip buffer.\n\nCan we have a 4th option where we bypass the conf?\nWe could make a conf struct in the test.\nBut still need to provide a filepath as `string` to streamTsv.\n\nA 5th option would be to use something else than go test, just bash.\nMaybe the best option for end-to-end test.\nWhile `go test` would be good for unit tests.\n\nLet's see how this 5th option would work.\nWould need to access an mmpio binary?\nOr just with go run maybe.\n\"The exit status of Run is not the exit status of the compiled binary.\"\nHmm.\n\nOtherwise I can add a build step in the test.sh, but then how to turn\nthe test TSV into a GZIP and inject the path somehow in the conf file?\n\nSo we can just do option 5, and provide the gzip path in the conf and\nmake this gzip file on test run.\n\nGH actions fails because the test action doesn't have a build step\nso our test script cannot find a ./mmpio to run.\n\nTest working as expected on GH actions! :tada:\n\n\nNow onto second test, and refactor a little the common bash bits.","shortMessageHtmlLink":"add testing"}},{"before":"8aaef2a7da2ea55185c1c62a4aa6ea5e664fbd19","after":"0aa84386773efc44559d3bf8aafd7f31a5726834","ref":"refs/heads/push-nusrmwpwlzsk","pushedAt":"2024-02-06T11:18:11.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"vincent-octo","name":"vincent","path":"/vincent-octo","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/4919840?s=80&v=4"},"commit":{"message":"add testing\n\nProblem: there is currently no automatic tests for mmpio, making it\ndifficult to find regression, trust the system, do refactoring.\n\nWhat I am about to do: think what kind of tests I want (i.e. what will\nthe tests cover), implement them, make sure they are automatic and\ntheir status is in a tight feedback loop.\n\nWhat I expect the result to be: implemented a couple of tests (not\ncovering the whole codebase, but at least enough so that for the next\nchange I can write a test with the same system); integrated in GitHub\nactions with clear status.\n\n\n* 2024-02-02  Let's start simple\nWhat would be the simplest test?\nMaybe one where we have 2 rows as input, and just get 1 in the output\nwith the p-value < 1e-6.\n\nI could use go embeds to have input & output files as plain text files,\nbut make easier (?), slicker (?) to deal with in Go code.\nNot sure if good long-term decision, but looks fun! Hype!\n\nOK, starting with making a dummy test to understand how `go test` work\nand get going.\n\nSeems `go test` is looking for *_test.go files.\n\nErr, seems there is some (bad) interactions between the flags package\nand testing?\n\nBy injecting a `fmt.Println(os.Args)` I can see that the program is\ncalled with:\n.../mmpio.test -test.paniconexit0 -test.timeout=10m0s\n\nRemoving the custom Usage function doesn't remove the error.\n\nRead about the interaction between init() and flag and testing at:\nhttps://go.dev/doc/go1.13#testingpkgtesting\n\nFixed go test run bug by changing my code to init the flag in main()\ninstead of init().\n\nNow basic dummy test is working as expected.\n\n\n* 2024-02-06\nChecking status. I should be able to run `go test` and have the dummy\ntest PASS or FAIL.\nWorking as expected.\n\nNow turning that into a real test.\nMaking the dummy data first.\n\nHmm, sum stats are expected to be gzip-compressed.\nLet's see.\n\nArh. I don't want to put gzipped data files in Git.\nIt will just make it harder to simply read and write.\n\nWhat are my options:\n1. embed the tsv file, then gzip it during test\n2. refactor the main mmpio funcs to allow a compression argument\n3. refactor to specify the compression in config file\n\nOption (1.) seems the best since we won't benefit from the refactoring\noptions elsewhere.\nBut is it possible? Our current process is that we provide a filepath,\nnot a gzip buffer.\n\nCan we have a 4th option where we bypass the conf?\nWe could make a conf struct in the test.\nBut still need to provide a filepath as `string` to streamTsv.\n\nA 5th option would be to use something else than go test, just bash.\nMaybe the best option for end-to-end test.\nWhile `go test` would be good for unit tests.\n\nLet's see how this 5th option would work.\nWould need to access an mmpio binary?\nOr just with go run maybe.\n\"The exit status of Run is not the exit status of the compiled binary.\"\nHmm.\n\nOtherwise I can add a build step in the test.sh, but then how to turn\nthe test TSV into a GZIP and inject the path somehow in the conf file?\n\nSo we can just do option 5, and provide the gzip path in the conf and\nmake this gzip file on test run.\n\nGH actions fails because the test action doesn't have a build step\nso our test script cannot find a ./mmpio to run.\n\nTest working as expected on GH actions! :tada:\n\n\nNow onto second test, and refactor a little the common bash bits.","shortMessageHtmlLink":"add testing"}},{"before":"f5e2182559a6719eb49bbe4174d8abe73b1f35d0","after":"8aaef2a7da2ea55185c1c62a4aa6ea5e664fbd19","ref":"refs/heads/push-nusrmwpwlzsk","pushedAt":"2024-02-06T11:16:54.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"vincent-octo","name":"vincent","path":"/vincent-octo","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/4919840?s=80&v=4"},"commit":{"message":"add testing\n\nProblem: there is currently no automatic tests for mmpio, making it\ndifficult to find regression, trust the system, do refactoring.\n\nWhat I am about to do: think what kind of tests I want (i.e. what will\nthe tests cover), implement them, make sure they are automatic and\ntheir status is in a tight feedback loop.\n\nWhat I expect the result to be: implemented a couple of tests (not\ncovering the whole codebase, but at least enough so that for the next\nchange I can write a test with the same system); integrated in GitHub\nactions with clear status.\n\n\n* 2024-02-02  Let's start simple\nWhat would be the simplest test?\nMaybe one where we have 2 rows as input, and just get 1 in the output\nwith the p-value < 1e-6.\n\nI could use go embeds to have input & output files as plain text files,\nbut make easier (?), slicker (?) to deal with in Go code.\nNot sure if good long-term decision, but looks fun! Hype!\n\nOK, starting with making a dummy test to understand how `go test` work\nand get going.\n\nSeems `go test` is looking for *_test.go files.\n\nErr, seems there is some (bad) interactions between the flags package\nand testing?\n\nBy injecting a `fmt.Println(os.Args)` I can see that the program is\ncalled with:\n.../mmpio.test -test.paniconexit0 -test.timeout=10m0s\n\nRemoving the custom Usage function doesn't remove the error.\n\nRead about the interaction between init() and flag and testing at:\nhttps://go.dev/doc/go1.13#testingpkgtesting\n\nFixed go test run bug by changing my code to init the flag in main()\ninstead of init().\n\nNow basic dummy test is working as expected.\n\n\n* 2024-02-06\nChecking status. I should be able to run `go test` and have the dummy\ntest PASS or FAIL.\nWorking as expected.\n\nNow turning that into a real test.\nMaking the dummy data first.\n\nHmm, sum stats are expected to be gzip-compressed.\nLet's see.\n\nArh. I don't want to put gzipped data files in Git.\nIt will just make it harder to simply read and write.\n\nWhat are my options:\n1. embed the tsv file, then gzip it during test\n2. refactor the main mmpio funcs to allow a compression argument\n3. refactor to specify the compression in config file\n\nOption (1.) seems the best since we won't benefit from the refactoring\noptions elsewhere.\nBut is it possible? Our current process is that we provide a filepath,\nnot a gzip buffer.\n\nCan we have a 4th option where we bypass the conf?\nWe could make a conf struct in the test.\nBut still need to provide a filepath as `string` to streamTsv.\n\nA 5th option would be to use something else than go test, just bash.\nMaybe the best option for end-to-end test.\nWhile `go test` would be good for unit tests.\n\nLet's see how this 5th option would work.\nWould need to access an mmpio binary?\nOr just with go run maybe.\n\"The exit status of Run is not the exit status of the compiled binary.\"\nHmm.\n\nOtherwise I can add a build step in the test.sh, but then how to turn\nthe test TSV into a GZIP and inject the path somehow in the conf file?\n\nSo we can just do option 5, and provide the gzip path in the conf and\nmake this gzip file on test run.\n\nGH actions fails because the test action doesn't have a build step\nso our test script cannot find a ./mmpio to run.\n\nTest working as expected on GH actions! :tada:\n\n\nNow onto second test, and refactor a little the common bash bits.","shortMessageHtmlLink":"add testing"}},{"before":"024c7d33137852d55c97cabe37fbd5188f41ba58","after":"f5e2182559a6719eb49bbe4174d8abe73b1f35d0","ref":"refs/heads/push-nusrmwpwlzsk","pushedAt":"2024-02-06T11:14:43.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"vincent-octo","name":"vincent","path":"/vincent-octo","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/4919840?s=80&v=4"},"commit":{"message":"add testing\n\nProblem: there is currently no automatic tests for mmpio, making it\ndifficult to find regression, trust the system, do refactoring.\n\nWhat I am about to do: think what kind of tests I want (i.e. what will\nthe tests cover), implement them, make sure they are automatic and\ntheir status is in a tight feedback loop.\n\nWhat I expect the result to be: implemented a couple of tests (not\ncovering the whole codebase, but at least enough so that for the next\nchange I can write a test with the same system); integrated in GitHub\nactions with clear status.\n\n\n* 2024-02-02  Let's start simple\nWhat would be the simplest test?\nMaybe one where we have 2 rows as input, and just get 1 in the output\nwith the p-value < 1e-6.\n\nI could use go embeds to have input & output files as plain text files,\nbut make easier (?), slicker (?) to deal with in Go code.\nNot sure if good long-term decision, but looks fun! Hype!\n\nOK, starting with making a dummy test to understand how `go test` work\nand get going.\n\nSeems `go test` is looking for *_test.go files.\n\nErr, seems there is some (bad) interactions between the flags package\nand testing?\n\nBy injecting a `fmt.Println(os.Args)` I can see that the program is\ncalled with:\n.../mmpio.test -test.paniconexit0 -test.timeout=10m0s\n\nRemoving the custom Usage function doesn't remove the error.\n\nRead about the interaction between init() and flag and testing at:\nhttps://go.dev/doc/go1.13#testingpkgtesting\n\nFixed go test run bug by changing my code to init the flag in main()\ninstead of init().\n\nNow basic dummy test is working as expected.\n\n\n* 2024-02-06\nChecking status. I should be able to run `go test` and have the dummy\ntest PASS or FAIL.\nWorking as expected.\n\nNow turning that into a real test.\nMaking the dummy data first.\n\nHmm, sum stats are expected to be gzip-compressed.\nLet's see.\n\nArh. I don't want to put gzipped data files in Git.\nIt will just make it harder to simply read and write.\n\nWhat are my options:\n1. embed the tsv file, then gzip it during test\n2. refactor the main mmpio funcs to allow a compression argument\n3. refactor to specify the compression in config file\n\nOption (1.) seems the best since we won't benefit from the refactoring\noptions elsewhere.\nBut is it possible? Our current process is that we provide a filepath,\nnot a gzip buffer.\n\nCan we have a 4th option where we bypass the conf?\nWe could make a conf struct in the test.\nBut still need to provide a filepath as `string` to streamTsv.\n\nA 5th option would be to use something else than go test, just bash.\nMaybe the best option for end-to-end test.\nWhile `go test` would be good for unit tests.\n\nLet's see how this 5th option would work.\nWould need to access an mmpio binary?\nOr just with go run maybe.\n\"The exit status of Run is not the exit status of the compiled binary.\"\nHmm.\n\nOtherwise I can add a build step in the test.sh, but then how to turn\nthe test TSV into a GZIP and inject the path somehow in the conf file?\n\nSo we can just do option 5, and provide the gzip path in the conf and\nmake this gzip file on test run.\n\nGH actions fails because the test action doesn't have a build step\nso our test script cannot find a ./mmpio to run.\n\nTest working as expected on GH actions! :tada:\n\n\nNow onto second test, and refactor a little the common bash bits.","shortMessageHtmlLink":"add testing"}},{"before":"cd62c21d6aad9d74ef059094e00b480039bc0a05","after":"024c7d33137852d55c97cabe37fbd5188f41ba58","ref":"refs/heads/push-nusrmwpwlzsk","pushedAt":"2024-02-06T11:13:47.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"vincent-octo","name":"vincent","path":"/vincent-octo","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/4919840?s=80&v=4"},"commit":{"message":"add testing\n\nProblem: there is currently no automatic tests for mmpio, making it\ndifficult to find regression, trust the system, do refactoring.\n\nWhat I am about to do: think what kind of tests I want (i.e. what will\nthe tests cover), implement them, make sure they are automatic and\ntheir status is in a tight feedback loop.\n\nWhat I expect the result to be: implemented a couple of tests (not\ncovering the whole codebase, but at least enough so that for the next\nchange I can write a test with the same system); integrated in GitHub\nactions with clear status.\n\n\n* 2024-02-02  Let's start simple\nWhat would be the simplest test?\nMaybe one where we have 2 rows as input, and just get 1 in the output\nwith the p-value < 1e-6.\n\nI could use go embeds to have input & output files as plain text files,\nbut make easier (?), slicker (?) to deal with in Go code.\nNot sure if good long-term decision, but looks fun! Hype!\n\nOK, starting with making a dummy test to understand how `go test` work\nand get going.\n\nSeems `go test` is looking for *_test.go files.\n\nErr, seems there is some (bad) interactions between the flags package\nand testing?\n\nBy injecting a `fmt.Println(os.Args)` I can see that the program is\ncalled with:\n.../mmpio.test -test.paniconexit0 -test.timeout=10m0s\n\nRemoving the custom Usage function doesn't remove the error.\n\nRead about the interaction between init() and flag and testing at:\nhttps://go.dev/doc/go1.13#testingpkgtesting\n\nFixed go test run bug by changing my code to init the flag in main()\ninstead of init().\n\nNow basic dummy test is working as expected.\n\n\n* 2024-02-06\nChecking status. I should be able to run `go test` and have the dummy\ntest PASS or FAIL.\nWorking as expected.\n\nNow turning that into a real test.\nMaking the dummy data first.\n\nHmm, sum stats are expected to be gzip-compressed.\nLet's see.\n\nArh. I don't want to put gzipped data files in Git.\nIt will just make it harder to simply read and write.\n\nWhat are my options:\n1. embed the tsv file, then gzip it during test\n2. refactor the main mmpio funcs to allow a compression argument\n3. refactor to specify the compression in config file\n\nOption (1.) seems the best since we won't benefit from the refactoring\noptions elsewhere.\nBut is it possible? Our current process is that we provide a filepath,\nnot a gzip buffer.\n\nCan we have a 4th option where we bypass the conf?\nWe could make a conf struct in the test.\nBut still need to provide a filepath as `string` to streamTsv.\n\nA 5th option would be to use something else than go test, just bash.\nMaybe the best option for end-to-end test.\nWhile `go test` would be good for unit tests.\n\nLet's see how this 5th option would work.\nWould need to access an mmpio binary?\nOr just with go run maybe.\n\"The exit status of Run is not the exit status of the compiled binary.\"\nHmm.\n\nOtherwise I can add a build step in the test.sh, but then how to turn\nthe test TSV into a GZIP and inject the path somehow in the conf file?\n\nSo we can just do option 5, and provide the gzip path in the conf and\nmake this gzip file on test run.\n\nGH actions fails because the test action doesn't have a build step\nso our test script cannot find a ./mmpio to run.\n\nTest working as expected on GH actions! :tada:\n\n\nNow onto second test, and refactor a little the common bash bits.","shortMessageHtmlLink":"add testing"}},{"before":"f5ad060f28a00dbc5401fa48f3ce90beb58fcd86","after":"e02c97466e19af94dbaff07a794e48a715d23690","ref":"refs/heads/push-swtvnxsyqxkw","pushedAt":"2024-02-06T10:04:50.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"vincent-octo","name":"vincent","path":"/vincent-octo","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/4919840?s=80&v=4"},"commit":{"message":"github actions: make pre-release on tag\n\nadd testing\n\nProblem: there is currently no automatic tests for mmpio, making it\ndifficult to find regression, trust the system, do refactoring.\n\nWhat I am about to do: think what kind of tests I want (i.e. what will\nthe tests cover), implement them, make sure they are automatic and\ntheir status is in a tight feedback loop.\n\nWhat I expect the result to be: implemented a couple of tests (not\ncovering the whole codebase, but at least enough so that for the next\nchange I can write a test with the same system); integrated in GitHub\nactions with clear status.\n\n\n* 2024-02-02  Let's start simple\nWhat would be the simplest test?\nMaybe one where we have 2 rows as input, and just get 1 in the output\nwith the p-value < 1e-6.\n\nI could use go embeds to have input & output files as plain text files,\nbut make easier (?), slicker (?) to deal with in Go code.\nNot sure if good long-term decision, but looks fun! Hype!\n\nOK, starting with making a dummy test to understand how `go test` work\nand get going.\n\nSeems `go test` is looking for *_test.go files.\n\nErr, seems there is some (bad) interactions between the flags package\nand testing?\n\nBy injecting a `fmt.Println(os.Args)` I can see that the program is\ncalled with:\n.../mmpio.test -test.paniconexit0 -test.timeout=10m0s\n\nRemoving the custom Usage function doesn't remove the error.\n\nRead about the interaction between init() and flag and testing at:\nhttps://go.dev/doc/go1.13#testingpkgtesting\n\nFixed go test run bug by changing my code to init the flag in main()\ninstead of init().\n\nNow basic dummy test is working as expected.\n\n\n* 2024-02-06\nChecking status. I should be able to run `go test` and have the dummy\ntest PASS or FAIL.\nWorking as expected.\n\nNow turning that into a real test.\nMaking the dummy data first.\n\nHmm, sum stats are expected to be gzip-compressed.\nLet's see.\n\nArh. I don't want to put gzipped data files in Git.\nIt will just make it harder to simply read and write.\n\nWhat are my options:\n1. embed the tsv file, then gzip it during test\n2. refactor the main mmpio funcs to allow a compression argument\n3. refactor to specify the compression in config file\n\nOption (1.) seems the best since we won't benefit from the refactoring\noptions elsewhere.\nBut is it possible? Our current process is that we provide a filepath,\nnot a gzip buffer.\n\nCan we have a 4th option where we bypass the conf?\nWe could make a conf struct in the test.\nBut still need to provide a filepath as `string` to streamTsv.\n\nA 5th option would be to use something else than go test, just bash.\nMaybe the best option for end-to-end test.\nWhile `go test` would be good for unit tests.\n\nLet's see how this 5th option would work.\nWould need to access an mmpio binary?\nOr just with go run maybe.\n\"The exit status of Run is not the exit status of the compiled binary.\"\nHmm.\n\nOtherwise I can add a build step in the test.sh, but then how to turn\nthe test TSV into a GZIP and inject the path somehow in the conf file?\n\nSo we can just do option 5, and provide the gzip path in the conf and\nmake this gzip file on test run.\n\nGH actions fails because the test action doesn't have a build step\nso our test script cannot find a ./mmpio to run.\n\nTest working as expected on GH actions! :tada:\n\n\nNow onto second test, and refactor a little the common bash bits.","shortMessageHtmlLink":"github actions: make pre-release on tag"}},{"before":null,"after":"f5ad060f28a00dbc5401fa48f3ce90beb58fcd86","ref":"refs/heads/push-swtvnxsyqxkw","pushedAt":"2024-02-06T10:04:11.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"vincent-octo","name":"vincent","path":"/vincent-octo","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/4919840?s=80&v=4"},"commit":{"message":"github actions: make pre-release on tag\n\nadd testing\n\nProblem: there is currently no automatic tests for mmpio, making it\ndifficult to find regression, trust the system, do refactoring.\n\nWhat I am about to do: think what kind of tests I want (i.e. what will\nthe tests cover), implement them, make sure they are automatic and\ntheir status is in a tight feedback loop.\n\nWhat I expect the result to be: implemented a couple of tests (not\ncovering the whole codebase, but at least enough so that for the next\nchange I can write a test with the same system); integrated in GitHub\nactions with clear status.\n\n\n* 2024-02-02  Let's start simple\nWhat would be the simplest test?\nMaybe one where we have 2 rows as input, and just get 1 in the output\nwith the p-value < 1e-6.\n\nI could use go embeds to have input & output files as plain text files,\nbut make easier (?), slicker (?) to deal with in Go code.\nNot sure if good long-term decision, but looks fun! Hype!\n\nOK, starting with making a dummy test to understand how `go test` work\nand get going.\n\nSeems `go test` is looking for *_test.go files.\n\nErr, seems there is some (bad) interactions between the flags package\nand testing?\n\nBy injecting a `fmt.Println(os.Args)` I can see that the program is\ncalled with:\n.../mmpio.test -test.paniconexit0 -test.timeout=10m0s\n\nRemoving the custom Usage function doesn't remove the error.\n\nRead about the interaction between init() and flag and testing at:\nhttps://go.dev/doc/go1.13#testingpkgtesting\n\nFixed go test run bug by changing my code to init the flag in main()\ninstead of init().\n\nNow basic dummy test is working as expected.\n\n\n* 2024-02-06\nChecking status. I should be able to run `go test` and have the dummy\ntest PASS or FAIL.\nWorking as expected.\n\nNow turning that into a real test.\nMaking the dummy data first.\n\nHmm, sum stats are expected to be gzip-compressed.\nLet's see.\n\nArh. I don't want to put gzipped data files in Git.\nIt will just make it harder to simply read and write.\n\nWhat are my options:\n1. embed the tsv file, then gzip it during test\n2. refactor the main mmpio funcs to allow a compression argument\n3. refactor to specify the compression in config file\n\nOption (1.) seems the best since we won't benefit from the refactoring\noptions elsewhere.\nBut is it possible? Our current process is that we provide a filepath,\nnot a gzip buffer.\n\nCan we have a 4th option where we bypass the conf?\nWe could make a conf struct in the test.\nBut still need to provide a filepath as `string` to streamTsv.\n\nA 5th option would be to use something else than go test, just bash.\nMaybe the best option for end-to-end test.\nWhile `go test` would be good for unit tests.\n\nLet's see how this 5th option would work.\nWould need to access an mmpio binary?\nOr just with go run maybe.\n\"The exit status of Run is not the exit status of the compiled binary.\"\nHmm.\n\nOtherwise I can add a build step in the test.sh, but then how to turn\nthe test TSV into a GZIP and inject the path somehow in the conf file?\n\nSo we can just do option 5, and provide the gzip path in the conf and\nmake this gzip file on test run.\n\nGH actions fails because the test action doesn't have a build step\nso our test script cannot find a ./mmpio to run.\n\nTest working as expected on GH actions! :tada:\n\n\nNow onto second test, and refactor a little the common bash bits.","shortMessageHtmlLink":"github actions: make pre-release on tag"}},{"before":"5ce89a6ba6995af326b5290da32174055f494bea","after":"cd62c21d6aad9d74ef059094e00b480039bc0a05","ref":"refs/heads/push-nusrmwpwlzsk","pushedAt":"2024-02-06T10:01:47.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"vincent-octo","name":"vincent","path":"/vincent-octo","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/4919840?s=80&v=4"},"commit":{"message":"add testing\n\nProblem: there is currently no automatic tests for mmpio, making it\ndifficult to find regression, trust the system, do refactoring.\n\nWhat I am about to do: think what kind of tests I want (i.e. what will\nthe tests cover), implement them, make sure they are automatic and\ntheir status is in a tight feedback loop.\n\nWhat I expect the result to be: implemented a couple of tests (not\ncovering the whole codebase, but at least enough so that for the next\nchange I can write a test with the same system); integrated in GitHub\nactions with clear status.\n\n\n* 2024-02-02  Let's start simple\nWhat would be the simplest test?\nMaybe one where we have 2 rows as input, and just get 1 in the output\nwith the p-value < 1e-6.\n\nI could use go embeds to have input & output files as plain text files,\nbut make easier (?), slicker (?) to deal with in Go code.\nNot sure if good long-term decision, but looks fun! Hype!\n\nOK, starting with making a dummy test to understand how `go test` work\nand get going.\n\nSeems `go test` is looking for *_test.go files.\n\nErr, seems there is some (bad) interactions between the flags package\nand testing?\n\nBy injecting a `fmt.Println(os.Args)` I can see that the program is\ncalled with:\n.../mmpio.test -test.paniconexit0 -test.timeout=10m0s\n\nRemoving the custom Usage function doesn't remove the error.\n\nRead about the interaction between init() and flag and testing at:\nhttps://go.dev/doc/go1.13#testingpkgtesting\n\nFixed go test run bug by changing my code to init the flag in main()\ninstead of init().\n\nNow basic dummy test is working as expected.\n\n\n* 2024-02-06\nChecking status. I should be able to run `go test` and have the dummy\ntest PASS or FAIL.\nWorking as expected.\n\nNow turning that into a real test.\nMaking the dummy data first.\n\nHmm, sum stats are expected to be gzip-compressed.\nLet's see.\n\nArh. I don't want to put gzipped data files in Git.\nIt will just make it harder to simply read and write.\n\nWhat are my options:\n1. embed the tsv file, then gzip it during test\n2. refactor the main mmpio funcs to allow a compression argument\n3. refactor to specify the compression in config file\n\nOption (1.) seems the best since we won't benefit from the refactoring\noptions elsewhere.\nBut is it possible? Our current process is that we provide a filepath,\nnot a gzip buffer.\n\nCan we have a 4th option where we bypass the conf?\nWe could make a conf struct in the test.\nBut still need to provide a filepath as `string` to streamTsv.\n\nA 5th option would be to use something else than go test, just bash.\nMaybe the best option for end-to-end test.\nWhile `go test` would be good for unit tests.\n\nLet's see how this 5th option would work.\nWould need to access an mmpio binary?\nOr just with go run maybe.\n\"The exit status of Run is not the exit status of the compiled binary.\"\nHmm.\n\nOtherwise I can add a build step in the test.sh, but then how to turn\nthe test TSV into a GZIP and inject the path somehow in the conf file?\n\nSo we can just do option 5, and provide the gzip path in the conf and\nmake this gzip file on test run.\n\nGH actions fails because the test action doesn't have a build step\nso our test script cannot find a ./mmpio to run.\n\nTest working as expected on GH actions! :tada:\n\n\nNow onto second test, and refactor a little the common bash bits.","shortMessageHtmlLink":"add testing"}},{"before":"63efa706ab09a5380d5af2b5e576935ca19ae2a4","after":"5ce89a6ba6995af326b5290da32174055f494bea","ref":"refs/heads/push-nusrmwpwlzsk","pushedAt":"2024-02-06T09:56:05.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"vincent-octo","name":"vincent","path":"/vincent-octo","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/4919840?s=80&v=4"},"commit":{"message":"add testing\n\nProblem: there is currently no automatic tests for mmpio, making it\ndifficult to find regression, trust the system, do refactoring.\n\nWhat I am about to do: think what kind of tests I want (i.e. what will\nthe tests cover), implement them, make sure they are automatic and\ntheir status is in a tight feedback loop.\n\nWhat I expect the result to be: implemented a couple of tests (not\ncovering the whole codebase, but at least enough so that for the next\nchange I can write a test with the same system); integrated in GitHub\nactions with clear status.\n\n\n* 2024-02-02  Let's start simple\nWhat would be the simplest test?\nMaybe one where we have 2 rows as input, and just get 1 in the output\nwith the p-value < 1e-6.\n\nI could use go embeds to have input & output files as plain text files,\nbut make easier (?), slicker (?) to deal with in Go code.\nNot sure if good long-term decision, but looks fun! Hype!\n\nOK, starting with making a dummy test to understand how `go test` work\nand get going.\n\nSeems `go test` is looking for *_test.go files.\n\nErr, seems there is some (bad) interactions between the flags package\nand testing?\n\nBy injecting a `fmt.Println(os.Args)` I can see that the program is\ncalled with:\n.../mmpio.test -test.paniconexit0 -test.timeout=10m0s\n\nRemoving the custom Usage function doesn't remove the error.\n\nRead about the interaction between init() and flag and testing at:\nhttps://go.dev/doc/go1.13#testingpkgtesting\n\nFixed go test run bug by changing my code to init the flag in main()\ninstead of init().\n\nNow basic dummy test is working as expected.\n\n\n* 2024-02-06\nChecking status. I should be able to run `go test` and have the dummy\ntest PASS or FAIL.\nWorking as expected.\n\nNow turning that into a real test.\nMaking the dummy data first.\n\nHmm, sum stats are expected to be gzip-compressed.\nLet's see.\n\nArh. I don't want to put gzipped data files in Git.\nIt will just make it harder to simply read and write.\n\nWhat are my options:\n1. embed the tsv file, then gzip it during test\n2. refactor the main mmpio funcs to allow a compression argument\n3. refactor to specify the compression in config file\n\nOption (1.) seems the best since we won't benefit from the refactoring\noptions elsewhere.\nBut is it possible? Our current process is that we provide a filepath,\nnot a gzip buffer.\n\nCan we have a 4th option where we bypass the conf?\nWe could make a conf struct in the test.\nBut still need to provide a filepath as `string` to streamTsv.\n\nA 5th option would be to use something else than go test, just bash.\nMaybe the best option for end-to-end test.\nWhile `go test` would be good for unit tests.\n\nLet's see how this 5th option would work.\nWould need to access an mmpio binary?\nOr just with go run maybe.\n\"The exit status of Run is not the exit status of the compiled binary.\"\nHmm.\n\nOtherwise I can add a build step in the test.sh, but then how to turn\nthe test TSV into a GZIP and inject the path somehow in the conf file?\n\nSo we can just do option 5, and provide the gzip path in the conf and\nmake this gzip file on test run.\n\nGH actions fails because the test action doesn't have a build step\nso our test script cannot find a ./mmpio to run.","shortMessageHtmlLink":"add testing"}},{"before":"0ee7e1301e8167d1f1ea539a8d519fca22df8c9b","after":"63efa706ab09a5380d5af2b5e576935ca19ae2a4","ref":"refs/heads/push-nusrmwpwlzsk","pushedAt":"2024-02-06T09:55:38.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"vincent-octo","name":"vincent","path":"/vincent-octo","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/4919840?s=80&v=4"},"commit":{"message":"add testing\n\nProblem: there is currently no automatic tests for mmpio, making it\ndifficult to find regression, trust the system, do refactoring.\n\nWhat I am about to do: think what kind of tests I want (i.e. what will\nthe tests cover), implement them, make sure they are automatic and\ntheir status is in a tight feedback loop.\n\nWhat I expect the result to be: implemented a couple of tests (not\ncovering the whole codebase, but at least enough so that for the next\nchange I can write a test with the same system); integrated in GitHub\nactions with clear status.\n\n\n* 2024-02-02  Let's start simple\nWhat would be the simplest test?\nMaybe one where we have 2 rows as input, and just get 1 in the output\nwith the p-value < 1e-6.\n\nI could use go embeds to have input & output files as plain text files,\nbut make easier (?), slicker (?) to deal with in Go code.\nNot sure if good long-term decision, but looks fun! Hype!\n\nOK, starting with making a dummy test to understand how `go test` work\nand get going.\n\nSeems `go test` is looking for *_test.go files.\n\nErr, seems there is some (bad) interactions between the flags package\nand testing?\n\nBy injecting a `fmt.Println(os.Args)` I can see that the program is\ncalled with:\n.../mmpio.test -test.paniconexit0 -test.timeout=10m0s\n\nRemoving the custom Usage function doesn't remove the error.\n\nRead about the interaction between init() and flag and testing at:\nhttps://go.dev/doc/go1.13#testingpkgtesting\n\nFixed go test run bug by changing my code to init the flag in main()\ninstead of init().\n\nNow basic dummy test is working as expected.\n\n\n* 2024-02-06\nChecking status. I should be able to run `go test` and have the dummy\ntest PASS or FAIL.\nWorking as expected.\n\nNow turning that into a real test.\nMaking the dummy data first.\n\nHmm, sum stats are expected to be gzip-compressed.\nLet's see.\n\nArh. I don't want to put gzipped data files in Git.\nIt will just make it harder to simply read and write.\n\nWhat are my options:\n1. embed the tsv file, then gzip it during test\n2. refactor the main mmpio funcs to allow a compression argument\n3. refactor to specify the compression in config file\n\nOption (1.) seems the best since we won't benefit from the refactoring\noptions elsewhere.\nBut is it possible? Our current process is that we provide a filepath,\nnot a gzip buffer.\n\nCan we have a 4th option where we bypass the conf?\nWe could make a conf struct in the test.\nBut still need to provide a filepath as `string` to streamTsv.\n\nA 5th option would be to use something else than go test, just bash.\nMaybe the best option for end-to-end test.\nWhile `go test` would be good for unit tests.\n\nLet's see how this 5th option would work.\nWould need to access an mmpio binary?\nOr just with go run maybe.\n\"The exit status of Run is not the exit status of the compiled binary.\"\nHmm.\n\nOtherwise I can add a build step in the test.sh, but then how to turn\nthe test TSV into a GZIP and inject the path somehow in the conf file?\n\nSo we can just do option 5, and provide the gzip path in the conf and\nmake this gzip file on test run.\n\nGH actions fails because the test action doesn't have a build step\nso our test script cannot find a ./mmpio to run.","shortMessageHtmlLink":"add testing"}},{"before":"634b3af7ace7257d3e0961c25cea8986d31154f4","after":"0ee7e1301e8167d1f1ea539a8d519fca22df8c9b","ref":"refs/heads/push-nusrmwpwlzsk","pushedAt":"2024-02-06T09:53:29.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"vincent-octo","name":"vincent","path":"/vincent-octo","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/4919840?s=80&v=4"},"commit":{"message":"add testing\n\nProblem: there is currently no automatic tests for mmpio, making it\ndifficult to find regression, trust the system, do refactoring.\n\nWhat I am about to do: think what kind of tests I want (i.e. what will\nthe tests cover), implement them, make sure they are automatic and\ntheir status is in a tight feedback loop.\n\nWhat I expect the result to be: implemented a couple of tests (not\ncovering the whole codebase, but at least enough so that for the next\nchange I can write a test with the same system); integrated in GitHub\nactions with clear status.\n\n\n* 2024-02-02  Let's start simple\nWhat would be the simplest test?\nMaybe one where we have 2 rows as input, and just get 1 in the output\nwith the p-value < 1e-6.\n\nI could use go embeds to have input & output files as plain text files,\nbut make easier (?), slicker (?) to deal with in Go code.\nNot sure if good long-term decision, but looks fun! Hype!\n\nOK, starting with making a dummy test to understand how `go test` work\nand get going.\n\nSeems `go test` is looking for *_test.go files.\n\nErr, seems there is some (bad) interactions between the flags package\nand testing?\n\nBy injecting a `fmt.Println(os.Args)` I can see that the program is\ncalled with:\n.../mmpio.test -test.paniconexit0 -test.timeout=10m0s\n\nRemoving the custom Usage function doesn't remove the error.\n\nRead about the interaction between init() and flag and testing at:\nhttps://go.dev/doc/go1.13#testingpkgtesting\n\nFixed go test run bug by changing my code to init the flag in main()\ninstead of init().\n\nNow basic dummy test is working as expected.\n\n\n* 2024-02-06\nChecking status. I should be able to run `go test` and have the dummy\ntest PASS or FAIL.\nWorking as expected.\n\nNow turning that into a real test.\nMaking the dummy data first.\n\nHmm, sum stats are expected to be gzip-compressed.\nLet's see.\n\nArh. I don't want to put gzipped data files in Git.\nIt will just make it harder to simply read and write.\n\nWhat are my options:\n1. embed the tsv file, then gzip it during test\n2. refactor the main mmpio funcs to allow a compression argument\n3. refactor to specify the compression in config file\n\nOption (1.) seems the best since we won't benefit from the refactoring\noptions elsewhere.\nBut is it possible? Our current process is that we provide a filepath,\nnot a gzip buffer.\n\nCan we have a 4th option where we bypass the conf?\nWe could make a conf struct in the test.\nBut still need to provide a filepath as `string` to streamTsv.\n\nA 5th option would be to use something else than go test, just bash.\nMaybe the best option for end-to-end test.\nWhile `go test` would be good for unit tests.\n\nLet's see how this 5th option would work.\nWould need to access an mmpio binary?\nOr just with go run maybe.\n\"The exit status of Run is not the exit status of the compiled binary.\"\nHmm.\n\nOtherwise I can add a build step in the test.sh, but then how to turn\nthe test TSV into a GZIP and inject the path somehow in the conf file?\n\nSo we can just do option 5, and provide the gzip path in the conf and\nmake this gzip file on test run.\n\nGH actions fails because the test action doesn't have a build step\nso our test script cannot find a ./mmpio to run.","shortMessageHtmlLink":"add testing"}},{"before":"c83c55bb6d0af1293e466b4fbd656e4a74ee65c1","after":"634b3af7ace7257d3e0961c25cea8986d31154f4","ref":"refs/heads/push-nusrmwpwlzsk","pushedAt":"2024-02-06T09:52:21.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"vincent-octo","name":"vincent","path":"/vincent-octo","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/4919840?s=80&v=4"},"commit":{"message":"add testing\n\nProblem: there is currently no automatic tests for mmpio, making it\ndifficult to find regression, trust the system, do refactoring.\n\nWhat I am about to do: think what kind of tests I want (i.e. what will\nthe tests cover), implement them, make sure they are automatic and\ntheir status is in a tight feedback loop.\n\nWhat I expect the result to be: implemented a couple of tests (not\ncovering the whole codebase, but at least enough so that for the next\nchange I can write a test with the same system); integrated in GitHub\nactions with clear status.\n\n\n* 2024-02-02  Let's start simple\nWhat would be the simplest test?\nMaybe one where we have 2 rows as input, and just get 1 in the output\nwith the p-value < 1e-6.\n\nI could use go embeds to have input & output files as plain text files,\nbut make easier (?), slicker (?) to deal with in Go code.\nNot sure if good long-term decision, but looks fun! Hype!\n\nOK, starting with making a dummy test to understand how `go test` work\nand get going.\n\nSeems `go test` is looking for *_test.go files.\n\nErr, seems there is some (bad) interactions between the flags package\nand testing?\n\nBy injecting a `fmt.Println(os.Args)` I can see that the program is\ncalled with:\n.../mmpio.test -test.paniconexit0 -test.timeout=10m0s\n\nRemoving the custom Usage function doesn't remove the error.\n\nRead about the interaction between init() and flag and testing at:\nhttps://go.dev/doc/go1.13#testingpkgtesting\n\nFixed go test run bug by changing my code to init the flag in main()\ninstead of init().\n\nNow basic dummy test is working as expected.\n\n\n* 2024-02-06\nChecking status. I should be able to run `go test` and have the dummy\ntest PASS or FAIL.\nWorking as expected.\n\nNow turning that into a real test.\nMaking the dummy data first.\n\nHmm, sum stats are expected to be gzip-compressed.\nLet's see.\n\nArh. I don't want to put gzipped data files in Git.\nIt will just make it harder to simply read and write.\n\nWhat are my options:\n1. embed the tsv file, then gzip it during test\n2. refactor the main mmpio funcs to allow a compression argument\n3. refactor to specify the compression in config file\n\nOption (1.) seems the best since we won't benefit from the refactoring\noptions elsewhere.\nBut is it possible? Our current process is that we provide a filepath,\nnot a gzip buffer.\n\nCan we have a 4th option where we bypass the conf?\nWe could make a conf struct in the test.\nBut still need to provide a filepath as `string` to streamTsv.\n\nA 5th option would be to use something else than go test, just bash.\nMaybe the best option for end-to-end test.\nWhile `go test` would be good for unit tests.\n\nLet's see how this 5th option would work.\nWould need to access an mmpio binary?\nOr just with go run maybe.\n\"The exit status of Run is not the exit status of the compiled binary.\"\nHmm.\n\nOtherwise I can add a build step in the test.sh, but then how to turn\nthe test TSV into a GZIP and inject the path somehow in the conf file?\n\nSo we can just do option 5, and provide the gzip path in the conf and\nmake this gzip file on test run.\n\nGH actions fails because the test action doesn't have a build step\nso our test script cannot find a ./mmpio to run.","shortMessageHtmlLink":"add testing"}},{"before":"e804d57a0fc1f72f758601dbf6c66eaf3c1aa3fc","after":"c83c55bb6d0af1293e466b4fbd656e4a74ee65c1","ref":"refs/heads/push-nusrmwpwlzsk","pushedAt":"2024-02-06T09:48:20.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"vincent-octo","name":"vincent","path":"/vincent-octo","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/4919840?s=80&v=4"},"commit":{"message":"add testing\n\nProblem: there is currently no automatic tests for mmpio, making it\ndifficult to find regression, trust the system, do refactoring.\n\nWhat I am about to do: think what kind of tests I want (i.e. what will\nthe tests cover), implement them, make sure they are automatic and\ntheir status is in a tight feedback loop.\n\nWhat I expect the result to be: implemented a couple of tests (not\ncovering the whole codebase, but at least enough so that for the next\nchange I can write a test with the same system); integrated in GitHub\nactions with clear status.\n\n\n* 2024-02-02  Let's start simple\nWhat would be the simplest test?\nMaybe one where we have 2 rows as input, and just get 1 in the output\nwith the p-value < 1e-6.\n\nI could use go embeds to have input & output files as plain text files,\nbut make easier (?), slicker (?) to deal with in Go code.\nNot sure if good long-term decision, but looks fun! Hype!\n\nOK, starting with making a dummy test to understand how `go test` work\nand get going.\n\nSeems `go test` is looking for *_test.go files.\n\nErr, seems there is some (bad) interactions between the flags package\nand testing?\n\nBy injecting a `fmt.Println(os.Args)` I can see that the program is\ncalled with:\n.../mmpio.test -test.paniconexit0 -test.timeout=10m0s\n\nRemoving the custom Usage function doesn't remove the error.\n\nRead about the interaction between init() and flag and testing at:\nhttps://go.dev/doc/go1.13#testingpkgtesting\n\nFixed go test run bug by changing my code to init the flag in main()\ninstead of init().\n\nNow basic dummy test is working as expected.\n\n\n\n\n* 2024-02-06\nChecking status. I should be able to run `go test` and have the dummy\ntest PASS or FAIL.\nWorking as expected.\n\nNow turning that into a real test.\nMaking the dummy data first.\n\nHmm, sum stats are expected to be gzip-compressed.\nLet's see.\n\nArh. I don't want to put gzipped data files in Git.\nIt will just make it harder to simply read and write.\n\nWhat are my options:\n1. embed the tsv file, then gzip it during test\n2. refactor the main mmpio funcs to allow a compression argument\n3. refactor to specify the compression in config file\n\nOption (1.) seems the best since we won't benefit from the refactoring\noptions elsewhere.\nBut is it possible? Our current process is that we provide a filepath,\nnot a gzip buffer.\n\nCan we have a 4th option where we bypass the conf?\nWe could make a conf struct in the test.\nBut still need to provide a filepath as `string` to streamTsv.\n\nA 5th option would be to use something else than go test, just bash.\nMaybe the best option for end-to-end test.\nWhile `go test` would be good for unit tests.\n\nLet's see how this 5th option would work.\nWould need to access an mmpio binary?\nOr just with go run maybe.\n\"The exit status of Run is not the exit status of the compiled binary.\"\nHmm.\n\nOtherwise I can add a build step in the test.sh, but then how to turn\nthe test TSV into a GZIP and inject the path somehow in the conf file?\n\nSo we can just do option 5, and provide the gzip path in the conf and\nmake this gzip file on test run.","shortMessageHtmlLink":"add testing"}},{"before":null,"after":"e804d57a0fc1f72f758601dbf6c66eaf3c1aa3fc","ref":"refs/heads/push-nusrmwpwlzsk","pushedAt":"2024-02-06T09:47:22.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"vincent-octo","name":"vincent","path":"/vincent-octo","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/4919840?s=80&v=4"},"commit":{"message":"add testing\n\nProblem: there is currently no automatic tests for mmpio, making it\ndifficult to find regression, trust the system, do refactoring.\n\nWhat I am about to do: think what kind of tests I want (i.e. what will\nthe tests cover), implement them, make sure they are automatic and\ntheir status is in a tight feedback loop.\n\nWhat I expect the result to be: implemented a couple of tests (not\ncovering the whole codebase, but at least enough so that for the next\nchange I can write a test with the same system); integrated in GitHub\nactions with clear status.\n\n\n* 2024-02-02  Let's start simple\nWhat would be the simplest test?\nMaybe one where we have 2 rows as input, and just get 1 in the output\nwith the p-value < 1e-6.\n\nI could use go embeds to have input & output files as plain text files,\nbut make easier (?), slicker (?) to deal with in Go code.\nNot sure if good long-term decision, but looks fun! Hype!\n\nOK, starting with making a dummy test to understand how `go test` work\nand get going.\n\nSeems `go test` is looking for *_test.go files.\n\nErr, seems there is some (bad) interactions between the flags package\nand testing?\n\nBy injecting a `fmt.Println(os.Args)` I can see that the program is\ncalled with:\n.../mmpio.test -test.paniconexit0 -test.timeout=10m0s\n\nRemoving the custom Usage function doesn't remove the error.\n\nRead about the interaction between init() and flag and testing at:\nhttps://go.dev/doc/go1.13#testingpkgtesting\n\nFixed go test run bug by changing my code to init the flag in main()\ninstead of init().\n\nNow basic dummy test is working as expected.\n\n\n\n\n* 2024-02-06\nChecking status. I should be able to run `go test` and have the dummy\ntest PASS or FAIL.\nWorking as expected.\n\nNow turning that into a real test.\nMaking the dummy data first.\n\nHmm, sum stats are expected to be gzip-compressed.\nLet's see.\n\nArh. I don't want to put gzipped data files in Git.\nIt will just make it harder to simply read and write.\n\nWhat are my options:\n1. embed the tsv file, then gzip it during test\n2. refactor the main mmpio funcs to allow a compression argument\n3. refactor to specify the compression in config file\n\nOption (1.) seems the best since we won't benefit from the refactoring\noptions elsewhere.\nBut is it possible? Our current process is that we provide a filepath,\nnot a gzip buffer.\n\nCan we have a 4th option where we bypass the conf?\nWe could make a conf struct in the test.\nBut still need to provide a filepath as `string` to streamTsv.\n\nA 5th option would be to use something else than go test, just bash.\nMaybe the best option for end-to-end test.\nWhile `go test` would be good for unit tests.\n\nLet's see how this 5th option would work.\nWould need to access an mmpio binary?\nOr just with go run maybe.\n\"The exit status of Run is not the exit status of the compiled binary.\"\nHmm.\n\nOtherwise I can add a build step in the test.sh, but then how to turn\nthe test TSV into a GZIP and inject the path somehow in the conf file?\n\nSo we can just do option 5, and provide the gzip path in the conf and\nmake this gzip file on test run.","shortMessageHtmlLink":"add testing"}},{"before":"93ff447900ddeb1a25e6b4d59fbebaf76dcb523a","after":"7c2ea4f74e03394c6a1a8e64bb7d792f6b302216","ref":"refs/heads/main","pushedAt":"2024-01-31T11:14:13.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"vincent-octo","name":"vincent","path":"/vincent-octo","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/4919840?s=80&v=4"},"commit":{"message":"github actions: make pre-release on tag","shortMessageHtmlLink":"github actions: make pre-release on tag"}},{"before":"93ff447900ddeb1a25e6b4d59fbebaf76dcb523a","after":null,"ref":"refs/tags/${tag_name}","pushedAt":"2024-01-31T11:13:44.000Z","pushType":"branch_deletion","commitsCount":0,"pusher":{"login":"vincent-octo","name":"vincent","path":"/vincent-octo","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/4919840?s=80&v=4"}},{"before":"a7385f98c83891f3b7c41a2b194064401a0989f4","after":null,"ref":"refs/tags/v1-test","pushedAt":"2024-01-31T11:13:41.000Z","pushType":"branch_deletion","commitsCount":0,"pusher":{"login":"vincent-octo","name":"vincent","path":"/vincent-octo","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/4919840?s=80&v=4"}},{"before":"723c7f8ee57ac4d4829a1c6d1fe7a476c841adfa","after":null,"ref":"refs/tags/v1-test2","pushedAt":"2024-01-31T11:13:37.000Z","pushType":"branch_deletion","commitsCount":0,"pusher":{"login":"vincent-octo","name":"vincent","path":"/vincent-octo","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/4919840?s=80&v=4"}},{"before":"0f56c0218ba26e519a9489f1edcb907b1d737b55","after":null,"ref":"refs/tags/v1-test3","pushedAt":"2024-01-31T11:13:34.000Z","pushType":"branch_deletion","commitsCount":0,"pusher":{"login":"vincent-octo","name":"vincent","path":"/vincent-octo","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/4919840?s=80&v=4"}},{"before":"d6311954813a9e6c5b61297343a6cd0996f2da07","after":null,"ref":"refs/tags/v1-test4","pushedAt":"2024-01-31T11:13:31.000Z","pushType":"branch_deletion","commitsCount":0,"pusher":{"login":"vincent-octo","name":"vincent","path":"/vincent-octo","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/4919840?s=80&v=4"}},{"before":"536c9d74ad332b3c2a368ddfef85d7cd680f5b3b","after":null,"ref":"refs/tags/v1-test5","pushedAt":"2024-01-31T11:13:28.000Z","pushType":"branch_deletion","commitsCount":0,"pusher":{"login":"vincent-octo","name":"vincent","path":"/vincent-octo","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/4919840?s=80&v=4"}},{"before":"22d1cc5f71a06d017ac6e45159bb95e7dfacc4a0","after":null,"ref":"refs/tags/v1-test6","pushedAt":"2024-01-31T11:13:25.000Z","pushType":"branch_deletion","commitsCount":0,"pusher":{"login":"vincent-octo","name":"vincent","path":"/vincent-octo","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/4919840?s=80&v=4"}},{"before":"f0ec65e15beeab4d4a79b456cacc4595e43a9f41","after":null,"ref":"refs/tags/v1-test7","pushedAt":"2024-01-31T11:13:22.000Z","pushType":"branch_deletion","commitsCount":0,"pusher":{"login":"vincent-octo","name":"vincent","path":"/vincent-octo","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/4919840?s=80&v=4"}},{"before":"494abf298323f5e648bf4a4a95b0e283845f1b72","after":null,"ref":"refs/tags/v1-test8","pushedAt":"2024-01-31T11:13:18.000Z","pushType":"branch_deletion","commitsCount":0,"pusher":{"login":"vincent-octo","name":"vincent","path":"/vincent-octo","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/4919840?s=80&v=4"}},{"before":"494abf298323f5e648bf4a4a95b0e283845f1b72","after":null,"ref":"refs/tags/v1-test9","pushedAt":"2024-01-31T11:13:15.000Z","pushType":"branch_deletion","commitsCount":0,"pusher":{"login":"vincent-octo","name":"vincent","path":"/vincent-octo","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/4919840?s=80&v=4"}},{"before":"699fc1418929fc249e0b078043d6ff0da9584516","after":null,"ref":"refs/tags/v1-test10","pushedAt":"2024-01-31T11:13:12.000Z","pushType":"branch_deletion","commitsCount":0,"pusher":{"login":"vincent-octo","name":"vincent","path":"/vincent-octo","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/4919840?s=80&v=4"}}],"hasNextPage":true,"hasPreviousPage":false,"activityType":"all","actor":null,"timePeriod":"all","sort":"DESC","perPage":30,"cursor":"djE6ks8AAAAD80ldKAA","startCursor":null,"endCursor":null}},"title":"Activity · FINNGEN/mmpio"}