Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Shake things up a bit around here #7

Merged
merged 1 commit into from
Apr 9, 2016
Merged

Shake things up a bit around here #7

merged 1 commit into from
Apr 9, 2016

Conversation

corsix
Copy link
Collaborator

@corsix corsix commented Apr 3, 2016

I would very much like to have something I can run in order to test whether my changes to LuaJIT are vaguely sensible. Thus far, the LuaJIT-test-cleanup repo has contained some very useful raw material, but efforts have somewhat stalled. As such, I would like to shake things up and attempt to inject some life:

  • Do away with the idea of being conservative and putting things under the experimental directory to start with. This whole repo is going to undergo enough flux, and is sufficiently experimental anyway, as to not need an experimental directory.
  • Throw away @ladc's experimental test runner. On the one hand, I'm sorry. On the other, I feel that it didn't function well in a number of areas:
    • It required lfs, which despite being a libary I like, is a dependency I'd really rather not have.
    • Its codestrings weren't constructed with a view of maintaining line numbers, making it more difficult than neccessary to interpret backtraces.
    • Even in verbose mode, it wouldn't print the currently executing test until after the test had completed. This is of no use when tests fail due to segfaults or C assertion failures (these being common failure scenarios when making heavy changes to LuaJIT internals).
  • Add a new test runner, and convert 250+ tests to the format it expects.

Some interesting features of my proposed runner are:

  • The --shuffle=SEED command line option to vary the order of tests.
  • The --slice=INDEX/NUM_SHARDS command line option for parallelising things. The idea here is to have a higher-level makefile specify say luajit test.lua --slice=1/8 through luajit test.lua --slice=8/8 in 8 separate targets, and then have a merging target afterwards, at which point make -jN for N in [1, 8] will run the test suite using N threads.
  • Tags with numeric values rather than just true/false.
  • index files, to avoid an lfs (or similar) dependency, to provide deterministic and controllable directory iteration order, and to allow for file/directory level tags/other-metadata.
  • A README.md file.

@Wiladams
Copy link
Collaborator

Wiladams commented Apr 3, 2016

I'd say go for it.

Having that specific test runner in 'experimental' has exactly served the intended
purpose. �It was not intrusive, and it's easy to dispose of.

I would also get rid of the "everything must be a pull request". �I really don't think
that's necessary. �I have write permissions to the repo, so creating pull requests
is superfluous, considering none of the history will be preserved in the end, and it
just slows down the process (demotivating for me).

Party on dude! �Start pushing, or pull requesting!

  • Shaping clay is easier than digging it out of the ground.

Date: Sun, 3 Apr 2016 14:47:07 -0700
From: notifications@github.com
To: LuaJIT-test-cleanup@noreply.github.com
Subject: [LuaJIT/LuaJIT-test-cleanup] Shake things up a bit around here (#7)

I would very much like to have something I can run in order to test
whether my changes to LuaJIT are vaguely sensible. Thus far, the
LuaJIT-test-cleanup repo has contained some very useful raw material,
but efforts have somewhat stalled. As such, I would like to shake
things up and attempt to inject some life:

  • Do away with the idea of being conservative and putting things
    under the experimental directory to start with. This whole repo is
    going to undergo enough flux, and is sufficiently experimental anyway,
    as to not need an experimental directory.
  • Throw away @ladchttps://github.com/ladc's experimental test
    runner. On the one hand, I'm sorry. On the other, I feel that it didn't
    function well in a number of areas:
  • It required lfs, which despite being a libary I like, is a
    dependency I'd really rather not have.
  • Its codestrings weren't constructed with a view of maintaining
    line numbers, making it more difficult than neccessary to interpret
    backtraces.
  • Even in verbose mode, it wouldn't print the currently
    executing test until after the test had completed. This is of no use
    when tests fail due to segfaults or C assertion failures (these being
    common failure scenarios when making heavy changes to LuaJIT
    internals).
  • Add a new test runner, and convert 250+ tests to the format it expects.

Some interesting features of my proposed runner are:

  • The --shuffle=SEED command line option to vary the order of tests.
  • The --slice=INDEX/NUM_SHARDS command line option for
    parallelising things. The idea here is to have a higher-level makefile
    specify say luajit test.lua --slice=1/8 through luajit test.lua
    --slice=8/8 in 8 separate targets, and then have a merging target
    afterwards, at which point make -jN for N in [1, 8] will run the test
    suite using N threads.
  • Tags with numeric values rather than just true/false.
  • index files, to avoid an lfs (or similar) dependency, to provide
    deterministic and controllable directory iteration order, and to allow
    for file/directory level tags/other-metadata.
  • A README.md file.

You can view, comment on, or merge this pull request online at:

#7

Commit Summary

  • Shake things up.

File Changes

Patch Links:

�
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on
GitHubhttps://github.com//pull/7

@corsix corsix merged commit c2da6d8 into LuaJIT:master Apr 9, 2016
@corsix corsix deleted the shakeup branch April 9, 2016 13:51
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

None yet
2 participants
@corsix @Wiladams