Another week has just begun, so what are you folks up to?
@Manishearth the same procedure as every week
Another week has just begun, so what are you folks up to?
@Manishearth the same procedure as every week
I have been merging pull request to my project rustorm from some other developers. Thanks to fellow rustaceans who have find my project useful. This is the first time that I started a project that really has pull requests(most are just hobby projects). This is encouraging and motivates me to continue hitting milestones on the project.
I'm:
Well I'm:
I'm doing some fiddling with no_std to see what it's like doing the really low-level stuff in Rust. Current issues are:
mainCRTStartup()
and __chkstk()
in order to link. I think mainCRTStartup()
is a known issue but __chkstk()
is a mystery to me."s\0t\0r\0i\0n\0g\0\0\0"
. I think I should be able to help this with syntax extension, but I haven't gone down that rabbit hole yet.Drop
impl from one of my classes which means it's technically unsafe.Hm, all the examples in that issue seem to be code that would be meaningless/very tricky to make useful even if did compile, so maybe there's something deeper going on. Maybe you could open a new thread here (or ask a question in the rust tag on stackoverflow) so you can get a bit more assistance?
Also, if by "technically unsafe" you mean memory unsafe (i.e. what the unsafe
keyword is used for, rather than a memory leak or something similar), then destructors aren't reliable enough even if they didn't ICE, e.g. creating a reference cycle with Rc
or Arc
(or, more easily, the std::mem::forget
function) allows one to skip running a destructor in safe code. Something like crossbeam::scope
is needed to get guarantees.
The case I ran into with that ICE was very different than the ones listed, so I should probably figure out a minimum example to add to the issue. "Unsafe" was also a bad choice of words on my part, I guess the issue is really that it doesn't clean up after itself properly. In theory this could lead to a leak of system resources, but in this particular case there's no issue because the OS cleans up everything on shutdown anyway.
Working on a safe Rust implementation of a decompressor for the Google Brotli compression format. I'm hoping that the final quality will be good enough for inclusion into a project like Servo. In my opinion, over-reliance on the C foreign function interface to consume existing libraries sacrifices many of the safety benefits of Rust. There needs to be a lot of work sunk into safe implementations of common format decoders like Zip, PNG, JPEG, etc...
It's an interesting exercise, because it really pushes the bit and byte twiddling capabilities of Rust. I'm also curious to see the trade-offs between safety and performance compared to a highly tuned C implementation.
Project site: GitHub - peter-bertok/brotli: A native Rust implementation of Google's Brotli compression format.
Original Google code: GitHub - google/brotli: Brotli compression format
I'm collecting a list of issues I find in Rust as I go along in the project Wiki: Home · peter-bertok/brotli Wiki · GitHub
I'll probably move those into a users.rust-lang.org post at some point...
fwiw, the Servo and Firefox devs violently agree! This is exactly where Rust is starting to infect Firefox (multiple severe exploits in bitmap decoding is, quite frankly, embarrassing).
Getting close to a proper release for my fst
crate, which can efficiently store and search large numbers of strings (hopefully > 1 billion). The trick is to compress the strings into an automaton (think prefix trie, but also compress suffixes), and then search in compressed space. Lots of cool streaming stuff thanks to mmap
: multiway set operations, regex searches, range queries and even construction of FSTs themselves. It has required me to do battle with streaming iterators. I won a small battle, but I think streaming iterators will win the war.
Probably at least another couple weeks just to write docs!
For the expect intrinsic. It is planned on being supported (as a pair of intrisics, likely
and unlikely
), I actually wrote an RFC for it, which has been accepted, so it's literally just a matter of time. That "time" being a refactor of the code in the compiler such that the intrinsics actually work.
In the meantime, I recommend using a macro for it so you can add them where they should be and then just update the macro when support lands.
I decided to implement the "Toom-3" multiplication algorithm in Ramp. Once you understand the general principle, the Toom-Cook algorithm is impressively elegant.
I have run into a slight snag with the interpolation sequence though, trying to figure out the best sequence for calculating the final coefficients is surprisingly tricky. I've been trying to work directly from the interpolation matrix, but I think doing Gaussian elimination by-hand, will work better, as elementary row operations are just basic operations on the 5 points I'm interpolating with. I can just keep track of the operations then translate those into code.
Once I'm done though, larger numbers should multiply much faster (larger being numbers with more than ~2000 decimal digits).
This week (as every week) I'll continue working on Iomrascálaí my AI for the game of Go. I'm currently running benchmarks on the improvements (strength wise) I did last week and as that takes a few days to complete maybe now is the time to write some issues (or Trello cards) that are actually understandable to other people. There's still too much only in my head.
If you decide to port sqlalchemy, I'll be glad to help!
Doesn't the wikipedia article give a sequence? (At least, for the points 0, 1, -1, -2, ∞.)
Sunday I tried Rust for the first time. Took user input, took all integers, doubled them, and then returned them. Documented my experience here: Getting started in Rust - General Programming - Ruby Programming Language Forum - MetaRuby
Monday I worked on implementing combinitorial count for combinatorics (math) using Test Driven Development. I have that working and uploaded here: GitHub - danielpclark/combinatorics
My only question so far is how can you, if possible, inline test a closure. I failed in attempts to test them so I had to move them out to external functions to test.
Next I will follow this blog post in integrating my new Rust methods into Ruby: Rust to the rescue (of Ruby). You are working with Ruby, probably… | by Fabiano B. | Medium and then benchmark it against my Ruby implementation of it.
Having only gotten started in Rust this week I absolutely love it! Although some discoveries are hard to come by... finding the need to unwrap() and use to_vec() took a good chunk of my day(s).
I have been working for several weeks now on introducing my fellow classmates and professors to Rust at a UK university.
As was probably expected, the students are initially more impressed with the mix of functional/OO programming in a way that makes sense to them, as many have not yet worked on projects where a garbage collector would be a huge limitation, (we do use C++, but not at the level where manual memory management is a huge pain yet, since these are mostly 3rd-year undergraduate students), so the memory-safety features are mostly seen as "nice to have" for them as of now, but it already made a few of them interested in more low-level dev and these do find the ownership model of great help, although there's an initial "fighting with the borrow checker" at first.
As for the professors, the memory-safety guarantees are definitely most of interest to them and I just got a word that there may even be some Rust-based modules next year to test the waters, however I do not want to go into specifics as nothing is "official" as of yet.
Basically, just wanted to say that I'm working hard at spreading Rust in my neck of the woods
Also, I am hoping to produce some more general Rust learning material soon-ish, (Videotutorials?), once I have more time.
Been doing more work on emulator-related things; started a graphical debugger for my Super Nintendo audio unit emulator (and also fixed most of the remaining bugs there!) using Qt for a frontend, and it's been super nice!
Also did some more work on coreaudio-rs trying to provide a safe rendering callback API while still allowing the stream format/data types to be changed at runtime. Going well, but lots of small details to hammer out before it's done.