Live data from Hacker News

Announcing Rust 1.16

blog.rust-lang.org

71–80 of 95 posts

Re: Announcing Rust 1.16

#71
post #48

Since Rust people read hn... the version 1.16 is at the bottom of https://thanks.rust-lang.org/ , while it should appear before 1.15

There's a bug open about this, and I am literally deploying the fix right now. It'll probably be fixed by the time you read this comment :) (EDIT: deployed successfully, refresh the page) Thank you!

Hi Steve, thank you. Can you link the bug so that I know where to look at the next time?

Re: Announcing Rust 1.16

#72
post #67

I'm wondering if the following will be one day possible with Rust. I want to build a fast data-store with the basic data-structures offered by Rust (e.g., std::collections), which are stored in a memory-mapped file. The problem with mmapped files is that they don't always appear at the same address (this is not always possible, especially if you open multiple stores at once). So in order to use the standard data-stru…

>I want to build a fast data-store Usually this means you want to build things build on arrays. >The problem with mmapped files is that they don't always appear at the same address i.e. you use arrays and then index into the array instead of using pointers. > So in order to use the standard data-structures, Rust must provide some mechanism to make this possible Well, arrays exist in Rust. Or you're going to have to b…

> Or you're going to have to be more specific about what you're trying to do.

I want to allocate arrays, maps, etcetera inside the region of a memory mapped file. Then, later, when I mmap the same file to a different region in memory, I want the arrays and maps to still work. That's all.

Re: Announcing Rust 1.16

#73
post #62

If you have a previous version of Rust installed, getting Rust 1.16 is as easy as: $ rustup update stable Nah. The old "rustup.sh" script doesn't install "rustup", the application. Rust isn't in the Ubuntu distribution, either. Stop rolling your own installer and use the distro programs. You are not a special snowflake.

No need to be hostile.

Re: Announcing Rust 1.16

#74
post #54

Earlier quoted context omitted.

I think it is unlikely we will make FreeBSD tier 1 any time soon. The project is stretched beyond its limits with its platform support commitments, and FreeBSD is historically difficult for us to support. The next tier 1 is going to be ARM, probably for both Android and Linux, and then I personally don't see any others on the horizon. I actually see our tiers being redefined soon to be more graduated, and not have so…

>So the most effective thing to do to take Rust FreeBSD support to the next level is to figure out a way to get the CI to run tests. If I were to set up my own FreeBSD buildbot for commits to the Rust repos, would result reports from my buildbot be welcome? Would automatic reports be useful to you, or should I manually inspect failures and write up a bug report / pull request with fixes for issues that arise? If auto…

We no longer use buildbot for our CI.

We have a "meta CI" system called bors/homu that integrates with other CI, currently Travis and AppVeyor. bors works with any service that can post a result to a GitHub PR.

So the plan for supporting further architectures is to create a small custom runner that builds, tests and posts to the PR. That code does not exist yet, but if it appeared there are likely several upcoming architectures that could make use of it.

With that tool, we could allow contributors to set up their own integration bots and hook into our CI.

Re: Announcing Rust 1.16

#75
post #71

Earlier quoted context omitted.

There's a bug open about this, and I am literally deploying the fix right now. It'll probably be fixed by the time you read this comment :) (EDIT: deployed successfully, refresh the page) Thank you!

Hi Steve, thank you. Can you link the bug so that I know where to look at the next time?

https://github.com/rust-lang-nursery/thanks/issues/61

Re: Announcing Rust 1.16

#77
post #72

Earlier quoted context omitted.

>I want to build a fast data-store Usually this means you want to build things build on arrays. >The problem with mmapped files is that they don't always appear at the same address i.e. you use arrays and then index into the array instead of using pointers. > So in order to use the standard data-structures, Rust must provide some mechanism to make this possible Well, arrays exist in Rust. Or you're going to have to b…

> Or you're going to have to be more specific about what you're trying to do. I want to allocate arrays, maps, etcetera inside the region of a memory mapped file. Then, later, when I mmap the same file to a different region in memory, I want the arrays and maps to still work. That's all.

There are several mmap crates, but they won't let you transparently use std::collections on top of them.

I imagine this will be possible once the custom allocators work sorts out.

Re: Announcing Rust 1.16

#78
post #72

Earlier quoted context omitted.

> Or you're going to have to be more specific about what you're trying to do. I want to allocate arrays, maps, etcetera inside the region of a memory mapped file. Then, later, when I mmap the same file to a different region in memory, I want the arrays and maps to still work. That's all.

There are several mmap crates, but they won't let you transparently use std::collections on top of them. I imagine this will be possible once the custom allocators work sorts out.

Just having custom allocators won't automatically fix the pointer issue: remapping the file later will leave the previously "allocated" pointers pointing into old memory, which may not be where the file was remapped.

The allocators and data structures would need to support using non-raw-pointer pointers types, including not even platform-pointer sized types.

Re: Announcing Rust 1.16

#79
post #72

Earlier quoted context omitted.

>I want to build a fast data-store Usually this means you want to build things build on arrays. >The problem with mmapped files is that they don't always appear at the same address i.e. you use arrays and then index into the array instead of using pointers. > So in order to use the standard data-structures, Rust must provide some mechanism to make this possible Well, arrays exist in Rust. Or you're going to have to b…

> Or you're going to have to be more specific about what you're trying to do. I want to allocate arrays, maps, etcetera inside the region of a memory mapped file. Then, later, when I mmap the same file to a different region in memory, I want the arrays and maps to still work. That's all.

Do you have examples of how this works in other languages? I would assume they have specialized data structures for this purpose.

Re: Announcing Rust 1.16

#80
post #78

Earlier quoted context omitted.

There are several mmap crates, but they won't let you transparently use std::collections on top of them. I imagine this will be possible once the custom allocators work sorts out.

Just having custom allocators won't automatically fix the pointer issue: remapping the file later will leave the previously "allocated" pointers pointing into old memory, which may not be where the file was remapped. The allocators and data structures would need to support using non-raw-pointer pointers types, including not even platform-pointer sized types.

Right. Makes sense.
Post reply on HN