Open MikePall opened 8 years ago
I'd like to be granted commit access to this repo
Done.
I would also like to contribute.
Done.
Since you added me are you ok with the syntax that telescope's uses for tests that you can see in my fork https://github.com/fsfod/LuaJIT-test-cleanup/commit/4a98d60118c093af73352e463d67c8938fd1ab6f. Telescope uses the same style as busted but is single file with no dependencies except for a separate pure lua command line runner.
I don't mind the syntax (better than busted). Converting everything to that style is straightforward, but maybe a bit premature.
IMHO the other organizational items from the README should be discussed first. Maybe open issues for them? But not 1:1, I wrote the list in a hurry. Sorry.
I guess a consistent naming scheme should be the first thing that needs to be agreed upon. Forget about the current test naming and grouping, though (that mess is entirely my fault).
After that, the tests could be split up, converted to the test support library style and commit-moved to a separate directory hierarchy under their new names.
Then one needs to comb through them and check whether they actually test what they are supposed to test. Some are quite old and the JIT compiler advanced enough in the meantime to turn them into empty loops. But don't forget that the interpreter needs to be exercised, too.
I have some quick input on non-x86/x64 testing:
Don't bother with native builds. Always perform cross-builds from an x86/x64 box, use QEMU user-mode (./configure --disable-kvm --disable-system --disable-user --enable-linux-user --target-list=ppc-linux-user,arm-linux-user,aarch64-linux-user,mips-linux-user,mipsel-linux-user
) and run tests against a sysroot (qemu-arm -cpu cortex-a9 -L /opt/armhf/sysroot
etc.). This simplifies testing (the tests have full local file system access) and massively cuts down on testing time compared to QEMU full-system emulation. GDB for QEMU user-mode is much more convenient, too.
Sorry, but I'm running out of time right now. I really wouldn't mind if you organize this yourselves. I've given @Wiladams, @ladc and @fsfod admin level access to this repo, so you can add more collaborators. Thank you!
I half expect to see a "John Galt" business card get left behind...
But honestly, thanks for setting this up. It will be a good proof point of how action oriented this community is.
Please add me as well :)
Done :-)
@ladc Thanks!
I'd like to contribute. It looks like no one's done a thing since the initial commit.
I did one thing as a test, it was backed out.
Rules of engagement: Even if you have direct access, do your work in a branch, or otherwise, and do pull requests.
The wiki outlines some naming conventions.
A test framework has been proposed, but no actual work has been submitted.
My suggestion would be to go ahead and do some prs.
Sent from my Windows Phone
From: Mark Rusichmailto:notifications@github.com Sent: 2/20/2016 8:44 AM To: LuaJIT/LuaJIT-test-cleanupmailto:LuaJIT-test-cleanup@noreply.github.com Cc: William Adamsmailto:william_a_adams@msn.com Subject: Re: [LuaJIT-test-cleanup] Commit access (#1)
I'd like to contribute. It looks like no one's done a thing since the initial commit.
Reply to this email directly or view it on GitHub: https://github.com/LuaJIT/LuaJIT-test-cleanup/issues/1#issuecomment-186648984
Requesting write access.
Done.
@MikePall I would like to help by adding the standard Lua 5.1 test suite (http://www.lua.org/tests/lua5.1-tests.tar.gz) - and possibly bits from later versions too. I do not know if these tests are already used but they don't appear to be. I have a lack of spare time so it will be a slow process, but it will give me great pleasure to help in this effort. If okay please grant me write access.
@dibyendumajumdar done. Make sure to check for any license /IP issues though.
Anyone who wants to help with the cleanup effort and feels qualified, please apply here for commit access to this repo.
Note: this does not automatically grant you commit access to the LuaJIT main repo, which is a tad more sensitive.