New week, new stuff. What are you folks up to?
I hope to finally get some work on semantic-rs done as well as researching 2 upcoming Rust talks.
A (very!) long time ago I started working on a little platformer using gfx-rs, but it ended up on hiatus (baby, university etc.). This week I’ll be picking it back up and will hopefully have something new to show in a week.
Just deployed a microservice (rewritten from Python to Rust) on staging env. Currently writing docs. I found it more convenient to write in a markdown editor and then paste back to
I’m working on a bunch of projects in the loop at the same time:
- https://github.com/emoon/tundra/tree/rust-support - Adding Rust support to Tundra. This is coming along and it’s now possible to add a Cargo project for binaries in there. Still things to sort out though.
- https://github.com/emoon/open_depacker - New project. Motivations for this one can be found on on the GH page.
- https://github.com/emoon/ProDBG/blob/rust - Work is progressing here as well. Moved bunch of the code over for the Window handling and now have a proper main function which doesn’t rely on callbacks which is way nicer. That also means i don’t need to do “tricks” for memory cleanup and such.
Thats about it
I just started rust after reading book 3 times . I’ll try to write my chip-8 emulator.
Feel free to critisize, I’d love some feedback!
Known issues: complete tests, more examples in docs
- Is it a good idea to have a
Verex.sourcereally be recreated all the time?
- Should I duplicate all the functions as constructors in
- Which methods should be public? (Maybe add warnings for the risky methods?)
I’ll continue to work on my evolutionary algorithms library (darwin-rs) and want to add multiple populations.
that’s neat. How do you do collision detection ? Self-made or is there a rust crate ?
I also wrote a platform game in python (snowball) that I would like to port to Rust someday.
Published New Rustacean e010: Macros rule!. Then promptly got schooled on all the things I got partly or wholly wrong! That response has a bunch of helpful links to discussions of the way macros currently behave, nearly all of which was news to me.
I have recently pushed up two different crates. The first, marid, is a library for managing parallel, long-running threads within a process. Notably, this crate exposes an easy interface for responding to signals as a shutdown mechanism. I have just published a small blog post detailing more about it.
The second crate is a Rust testing DSL in the TDD/BDD style. It is currently on v0.1.0, but is definitely usable for many different cases. Inspired by such matcher libraries as
ginkgo, my favorite feature is the support for async-style expectations with the
consistently assertions. For this crate I am really looking for information on what types of other matchers people would find useful, so please take a look at the current docs and let me know if there is anything you would want that is missing.
cool, thanks for the link. I’ll have a look into this.
I’m in the midst of some heavy refactoring in Gunship. As it turns out providing a convenient game engine API in a language as low-level as Rust isn’t super easy. Most of the techniques that I would use in a language like C# don’t really apply or undermine the whole point of using Rust in the first place. I have a good idea of the direction I’m headed in but only time (and a lot of work) is going to make it clear what the best system is.
I’ve been working to add n-ary heaps and B-trees to libreal, and playing with representations of hypercomplex numbers in Rust.
I’m trying to add a more module based system for yayd & get unit tests for everything, also running on travis.
I’ve been working on my first patch to Rust, and somehow spent a lot of yesterday trying to get appveyor to build Rust. (Verdict: we’ll need a pre-built LLVM, which isn’t surprising.) I’ve also been working on a library for multiprocess Rust, allowing running Rust functions in other processes. Fork without the exec.