profile
viewpoint

azriel91/autexousious 35

Main repository for Will -- 2.5D moddable action adventure game

amethyst/ludumdare42 17

A game made by the Amethyst team for Ludum Dare 42

azriel91/builder_macro 3

Rust macro to implement a struct and corresponding builder

azriel91/amethyst_engine_engine 1

Slides for Amethyst talk. 2019-02-25 Auckland Rust Meetup

azriel91/aos_vs_soa 1

Naive benchmark to show how the *struct of arrays* data layout benefits from caching to improve performance.

azriel91/autojump 1

A cd command that learns - easily navigate directories from the command line

azriel91/alga 0

Abstract algebra for Rust.

azriel91/amethyst 0

Data-oriented game engine written in Rust

azriel91/amethyst-drone-config 0

Done CI configuration template for building Amethyst games

azriel91/amethyst_gl_segfault 0

Minimal segfault reproduction

startedazriel91/srcerr

started time in 4 days

startedazriel91/srcerr

started time in 5 days

startedazriel91/srcerr

started time in 5 days

startedazriel91/srcerr

started time in 5 days

startedazriel91/srcerr

started time in 5 days

pull request commentamethyst/shred

Add `ci.yml` github actions workflow.

Timed out.

azriel91

comment created time in 5 days

delete branch amethyst/shred

delete branch : staging.tmp

delete time in 5 days

push eventamethyst/shred

bors[bot]

commit sha 3f4e2a097d349112eccd8442157d8cdfbd08b37e

Merge #201 201: Add `ci.yml` github actions workflow. r=azriel91 a=azriel91 Switch CI to use github actions, as bors isn't getting past travis (always times out). Co-authored-by: Azriel Hoh <azriel91@gmail.com>

view details

push time in 5 days

push eventamethyst/shred

Azriel Hoh

commit sha cfa1dbfdf83ce86bcb79cd78eda5f406389a87e8

Add `ci.yml` github actions workflow.

view details

Azriel Hoh

commit sha 2e18e0de109f4efa6ee67a87dee89e7500263988

Switch `bors.toml` to read `ci` workflow status.

view details

Azriel Hoh

commit sha 79a98abe8c51f372e53d624ecc821cf5cc3276b1

Remove `.travis.yml` and `ci-script.sh`

view details

Azriel Hoh

commit sha f01359c7a655625ab691c38000382ced3b50c64d

Update `README.md` CI badge to point to Github Actions.

view details

Azriel Hoh

commit sha 860251e29c69fd939d3041f040e709b898ef6de5

Remove Rustfmt job from CI.

view details

bors[bot]

commit sha cee30c1fc6e8e887a859c64d6a27b692b3fde73d

[ci skip][skip ci][skip netlify] -bors-staging-tmp-201

view details

push time in 5 days

create barnchamethyst/shred

branch : staging.tmp

created branch time in 5 days

pull request commentamethyst/shred

Add `ci.yml` github actions workflow.

Timed out.

azriel91

comment created time in 5 days

push eventamethyst/shred

Azriel Hoh

commit sha cfa1dbfdf83ce86bcb79cd78eda5f406389a87e8

Add `ci.yml` github actions workflow.

view details

Azriel Hoh

commit sha 2e18e0de109f4efa6ee67a87dee89e7500263988

Switch `bors.toml` to read `ci` workflow status.

view details

Azriel Hoh

commit sha 79a98abe8c51f372e53d624ecc821cf5cc3276b1

Remove `.travis.yml` and `ci-script.sh`

view details

Azriel Hoh

commit sha f01359c7a655625ab691c38000382ced3b50c64d

Update `README.md` CI badge to point to Github Actions.

view details

Azriel Hoh

commit sha 860251e29c69fd939d3041f040e709b898ef6de5

Remove Rustfmt job from CI.

view details

bors[bot]

commit sha a6d309be5c8fb641767f1b1de216a3518da17b20

Merge #201 201: Add `ci.yml` github actions workflow. r=azriel91 a=azriel91 Switch CI to use github actions, as bors isn't getting past travis (always times out). Co-authored-by: Azriel Hoh <azriel91@gmail.com>

view details

push time in 5 days

delete branch amethyst/shred

delete branch : staging.tmp

delete time in 5 days

push eventamethyst/shred

Azriel Hoh

commit sha cfa1dbfdf83ce86bcb79cd78eda5f406389a87e8

Add `ci.yml` github actions workflow.

view details

Azriel Hoh

commit sha 2e18e0de109f4efa6ee67a87dee89e7500263988

Switch `bors.toml` to read `ci` workflow status.

view details

Azriel Hoh

commit sha 79a98abe8c51f372e53d624ecc821cf5cc3276b1

Remove `.travis.yml` and `ci-script.sh`

view details

Azriel Hoh

commit sha f01359c7a655625ab691c38000382ced3b50c64d

Update `README.md` CI badge to point to Github Actions.

view details

Azriel Hoh

commit sha 860251e29c69fd939d3041f040e709b898ef6de5

Remove Rustfmt job from CI.

view details

bors[bot]

commit sha 808c3cbc4296ee373c8a9a4022335720d7194cf2

[ci skip][skip ci][skip netlify] -bors-staging-tmp-201

view details

push time in 5 days

create barnchamethyst/shred

branch : staging.tmp

created branch time in 5 days

pull request commentamethyst/shred

WIP/PoC: Batch api ergonomics

Timed out.

vorner

comment created time in 5 days

push eventamethyst/shred

bors[bot]

commit sha f3fe487275628816251ca1978eee37f3882f2f2c

Merge #198 198: WIP/PoC: Batch api ergonomics r=azriel91 a=vorner Hello As mentioned in #197, I've sketched some API how the batch dispatching could be improved so it's less awkward and doesn't require unsafe. This is very much a PoC/WiP, I don't want to merge it as it is. I know there are missing docs, copy-pasted comments that are out of context, extra includes that are no longer needed, some things are public when in fact shouldn't be and in general a lot of garbage. I plan to clean it up before asking for it to get merged. What I would like now is to have some feedback on the API. I have some specific questions, but any other suggestions are fine too: * Naming. In particular, the simpler case where it is decided up-front how many times the sub-dispatcher should run is currently called multi-batch. I think this is a bad name, because it suggests it's somehow „more“ than the usual but more complex case. * The multi-batch is a separate method of the builder. Alternatively, it could be exposed as the wrapper type and one could create it directly. I'm not sure on what's better. In general, however, I feel like this makes the API more approachable (obviously, after it gets some docs and examples). @azriel91 Do you think I should continue in this? (and, btw, there's a tiny doc update PR from me sitting there for some time as well). Co-authored-by: Michal 'vorner' Vaner <vorner@vorner.cz>

view details

push time in 5 days

delete branch amethyst/shred

delete branch : staging.tmp

delete time in 5 days

push eventamethyst/shred

Michal 'vorner' Vaner

commit sha d23c39275d6383add640cf2d11cfebf7f59920bf

Batch dispatching ergonomics * The dispatcher is now passed in as a value, so it can contain data. * No need to touch unsafe by the user. * Helper for the usual case where the number of times the batch is run is decided ahead of the time. Closes #197

view details

bors[bot]

commit sha 97220c294b3d6b21bbf880fd03fb4e7b578bc474

[ci skip][skip ci][skip netlify] -bors-staging-tmp-198

view details

push time in 5 days

create barnchamethyst/shred

branch : staging.tmp

created branch time in 5 days

pull request commentamethyst/shred

WIP/PoC: Batch api ergonomics

Is it timing in the tests (in some way I might be responsible for), or is it timing in submitting the tests to CI? I don't seem to be able to get to any kind of logs :-(.

vorner

comment created time in 6 days

pull request commentamethyst/shred

WIP/PoC: Batch api ergonomics

Timed out.

vorner

comment created time in 6 days

push eventamethyst/shred

bors[bot]

commit sha cd4b7c37be0728920b3292d7db8bc1ea572c6869

Merge #198 198: WIP/PoC: Batch api ergonomics r=azriel91 a=vorner Hello As mentioned in #197, I've sketched some API how the batch dispatching could be improved so it's less awkward and doesn't require unsafe. This is very much a PoC/WiP, I don't want to merge it as it is. I know there are missing docs, copy-pasted comments that are out of context, extra includes that are no longer needed, some things are public when in fact shouldn't be and in general a lot of garbage. I plan to clean it up before asking for it to get merged. What I would like now is to have some feedback on the API. I have some specific questions, but any other suggestions are fine too: * Naming. In particular, the simpler case where it is decided up-front how many times the sub-dispatcher should run is currently called multi-batch. I think this is a bad name, because it suggests it's somehow „more“ than the usual but more complex case. * The multi-batch is a separate method of the builder. Alternatively, it could be exposed as the wrapper type and one could create it directly. I'm not sure on what's better. In general, however, I feel like this makes the API more approachable (obviously, after it gets some docs and examples). @azriel91 Do you think I should continue in this? (and, btw, there's a tiny doc update PR from me sitting there for some time as well). Co-authored-by: Michal 'vorner' Vaner <vorner@vorner.cz>

view details

push time in 6 days

delete branch amethyst/shred

delete branch : staging.tmp

delete time in 6 days

push eventamethyst/shred

Michal 'vorner' Vaner

commit sha d23c39275d6383add640cf2d11cfebf7f59920bf

Batch dispatching ergonomics * The dispatcher is now passed in as a value, so it can contain data. * No need to touch unsafe by the user. * Helper for the usual case where the number of times the batch is run is decided ahead of the time. Closes #197

view details

bors[bot]

commit sha 2e832440caa6dc7002ffbb2104b385df780b929e

[ci skip][skip ci][skip netlify] -bors-staging-tmp-198

view details

push time in 6 days

create barnchamethyst/shred

branch : staging.tmp

created branch time in 6 days

pull request commentamethyst/shred

WIP/PoC: Batch api ergonomics

Timed out.

vorner

comment created time in 6 days

push eventamethyst/shred

bors[bot]

commit sha 481b358999450ef7db0a199f19888cb74d753f6a

Merge #198 198: WIP/PoC: Batch api ergonomics r=azriel91 a=vorner Hello As mentioned in #197, I've sketched some API how the batch dispatching could be improved so it's less awkward and doesn't require unsafe. This is very much a PoC/WiP, I don't want to merge it as it is. I know there are missing docs, copy-pasted comments that are out of context, extra includes that are no longer needed, some things are public when in fact shouldn't be and in general a lot of garbage. I plan to clean it up before asking for it to get merged. What I would like now is to have some feedback on the API. I have some specific questions, but any other suggestions are fine too: * Naming. In particular, the simpler case where it is decided up-front how many times the sub-dispatcher should run is currently called multi-batch. I think this is a bad name, because it suggests it's somehow „more“ than the usual but more complex case. * The multi-batch is a separate method of the builder. Alternatively, it could be exposed as the wrapper type and one could create it directly. I'm not sure on what's better. In general, however, I feel like this makes the API more approachable (obviously, after it gets some docs and examples). @azriel91 Do you think I should continue in this? (and, btw, there's a tiny doc update PR from me sitting there for some time as well). Co-authored-by: Michal 'vorner' Vaner <vorner@vorner.cz>

view details

push time in 6 days

delete branch amethyst/shred

delete branch : staging.tmp

delete time in 6 days

push eventamethyst/shred

Michal 'vorner' Vaner

commit sha d23c39275d6383add640cf2d11cfebf7f59920bf

Batch dispatching ergonomics * The dispatcher is now passed in as a value, so it can contain data. * No need to touch unsafe by the user. * Helper for the usual case where the number of times the batch is run is decided ahead of the time. Closes #197

view details

bors[bot]

commit sha 695f00dd75451e93d830ca48d71f4940cf3e0474

[ci skip][skip ci][skip netlify] -bors-staging-tmp-198

view details

push time in 6 days

more