Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Announcing Rust 1.16

blog.rust-lang.org

Post reply on HN
Print view View original

61–70 of 95 posts

Re: Announcing Rust 1.16

#61

Post by eriknstr »

steveklabnik wrote: post #60
eriknstr wrote: post #58

Earlier quoted context omitted.

>Given that we run these tests on every commit, in some sense, it would be the PR author's job, but if they get stuck, we need someone who's able to help them fix that. That is the hardest part of moving from tier 2 to tier 1 in my personal opinion. Who is that person? What happens if they drop off the project? I would have liked to volunteer as the kind of person that would investigate issues for the FreeBSD platfor…

Yeah, I think that policy is sound, it's just something we haven't actually done yet, so there are inevitable kinks to work out :) I expect that your situation isn't uncommon, maybe the solution is two or three people rather than one. Raises that bar though...

>maybe the solution is two or three people rather than one

Sounds like a good idea to me. Personally I would be willing to work with a couple of other volunteers as long as we were able to get along.

Re: Announcing Rust 1.16

#62

Post by Animats »

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.

Re: Announcing Rust 1.16

#63

Post by steveklabnik »

Animats wrote: 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.

> Nah. The old "rustup.sh" script doesn't install "rustup", the application.

rustup.sh has been deprecated for months now.

> Rust isn't in the Ubuntu distribution, either.

It's in Debian now, so (as far as I know) that means it should end up in Ubuntu soonish.

> Stop rolling your own installer and use the distro programs.

Not everyone is on Linux.

Re: Announcing Rust 1.16

#64

Post by conradev »

eridius wrote: post #44
conradev wrote: post #37

Earlier quoted context omitted.

I meant dylib files. You can't ship those, but you can ship dynamically linked frameworks.

AFAIK the only difference between a dylib and a framework is the folder structure (and I guess the install path of the library). So in theory you could produce a cdylib, create a framework folder structure for it, and then use install_name_tool to update the install name appropriately.

That's what I thought, too, but I was reminded of the filetype field in the mach_header which has distinct MH_DYLIB and MH_BUNDLE values. fwiw, I don't think that difference means much for the loading process, but they are different.

Re: Announcing Rust 1.16

#65

Post by koverstreet »

brson wrote: post #54
eriknstr wrote: post #50

I am glad that FreeBSD is on the "Tier 2" list of supported platforms [1] but am wondering, is there any way to convince you guys to make it "Tier 1"? If so, how? I am willing to dedicate some amount of my own time to make it happen but am not convinced that my skills [2] and the amount of time I have available to spend is sufficient to make a difference. [1]: https://forge.rust-lang.org/platform-support.html [2]: ht…

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…

I've got scripts that I use for my own kernel development that spin up a VM (using kvm), run a test inside the VM and give you pass/fail and test output on stdout.

If anyone is interested, it'd probably be quite easy to adapt for running rust tests inside a FreeBSD vm:

https://evilpiepirate.org/git/ktest.git

If anyone is interested I'd be happy to walk someone through what it does and what parts you'd want.

Re: Announcing Rust 1.16

#66

Post by eridius »

conradev wrote: post #64
eridius wrote: post #44

Earlier quoted context omitted.

AFAIK the only difference between a dylib and a framework is the folder structure (and I guess the install path of the library). So in theory you could produce a cdylib, create a framework folder structure for it, and then use install_name_tool to update the install name appropriately.

That's what I thought, too, but I was reminded of the filetype field in the mach_header which has distinct MH_DYLIB and MH_BUNDLE values. fwiw, I don't think that difference means much for the loading process, but they are different.

Hmm. I just ran `otool -hv /System/Library/Frameworks/Foundation.framework/Foundation` and it says the "filetype" header has the value "DYLIB". It looks like MH_BUNDLE is actually for plugin bundles, not for frameworks.

Re: Announcing Rust 1.16

#67

Post by amelius »

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-structures, Rust must provide some mechanism to make this possible (I realize that this can be tricky). Alternatively, I could write my own data-structures, but of course, I'd prefer to use the standard ones.

Re: Announcing Rust 1.16

#69

Post by fnord123 »

amelius wrote: 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 be more specific about what you're trying to do.

Re: Announcing Rust 1.16

#70

Post by conradev »

eridius wrote: post #66
conradev wrote: post #64

Earlier quoted context omitted.

That's what I thought, too, but I was reminded of the filetype field in the mach_header which has distinct MH_DYLIB and MH_BUNDLE values. fwiw, I don't think that difference means much for the loading process, but they are different.

Hmm. I just ran `otool -hv /System/Library/Frameworks/Foundation.framework/Foundation` and it says the "filetype" header has the value "DYLIB". It looks like MH_BUNDLE is actually for plugin bundles, not for frameworks.

Oh, I see! That makes sense. Preference bundles are type "BUNDLE" but frameworks are not. TIL.
Post reply on HN