silentk: Why might they exit?

Moongoodboy{K}: they are running GUI windows that may receive close events, so those threads would need to be joined before the other window / thread should be able to restart them

How is num shared between the threads?

Ownership goes to the thread from the mutex everytime it calls lock()?

silentk: `num` (declared on line 10 in that snippet) is a smart pointer representing a borrow of an i32 which is owned by the `Mutex`.

The Mutex owns the i32; lock() loans it to you.

…lends.

hi i have a question about structs and lifetimes

~ask @ iceiceice

iceiceice: Got a question about Rust? Go ahead and ask it! If you need to paste code, please use play.rust-lang.org and click "Share" for a link

I have a struct A that holds some data, and has no lifetime parameter, and B that depends on A and binds to its lifetime parameter.

I would like to combine these into one struct that abstracts this all and has no lifetime parameter

and make B use the lifeitme of the A member as its parameter

is that kind of thing possible or not?

i didn't see it in the docu

The type that wraps both of these would be a self-referential type, which are tricky.

You may be interested in {~crate rental}.

Also {~crate owning_ref}

why is it a self referential type?

The Struct C that holds A and B, contains a reference (in B) that Points to another part of C (in A)

are there rust fn's for setting mtime and atime?

What decides when there can be two versions of a crate. I have two third party dependencies on byteorder, one which oddly uses version "~1.2.1", the other "1.3.1". Which can't update due to the conflict but I've seem multiple versions of dependencies build before.

~ constraints interact poorly with cargo's dependency resolution

~1.2.1 means >= 1.2.0, < 1.3.0 iirc

but cargo won't build two 1.x versions because they should be compatible

I think klabnik is actually working on those types of problems now

there was a reddit post about him formalizing some of the version constraint specifications, etc

Why can't that dependency use 1.2.1 and the other 1.3.1. I know there can't be multiple versions of c sys crates, but I don't think should affect byteorder

I have a public function that returns a function which takes stuff out of a channel and pushes that to an http server using reqwest. In javascript for example, I'd put all dependencies as parameters with default values (then in a test I can override the dependency using a moc). What's the right way to do that in rust considering there's no default parameter values?

Is there a trello board etc somewhere for tracking and understanding the dependency issues in flight?

There are default values, and you can control initialization via adding some default traits.

I've implemented a ::default method, but I don't think it's quite the same.

silentk: So you're saying I should define a struct with the params that implements the default trait and pass that struct instead of parameters?

It's a bit verbose isn't it?

gchristensen: docs.rs/libc/0.2.48/libc/struct.stat.html

ldiamond: that seems like the way to go, create a tuple struct, e.g. FunParams(type1, type2, ...)

krobelus: doesn't seem like that allows setting?

oh! utimeensat

thanks!

gchristensen: i don't see it right now, how do you set the mtime? not with syscall i assume

touch can do it

krobelus: changing file timestamps is a syscall, yeah

Hey all. Why is Rustup telling me that there is no rustfmt component for x86_64 Darwin?

"error: toolchain 'stable-x86_64-apple-darwin' does not contain component 'rustfmt' for target 'x86_64-apple-darwin'"

neachdainn: What is the output of `rustc --version` and `rustup --version`?

rustc 1.32.0 (9fda7c223 2019-01-16) and rustup 1.16.0 (beab5ac2b 2018-12-06)

I thought I was on the latest Rustc, so update that and then try again

That did not fix it

neachdainn: May you share the output of `rustup component list` on paste.rs?

Here you go! paste.rs/pxD

I did install the preview on stable, but I'm really trying to install the nightly version and I'm getting the same error for both

I did install it on stable *a while ago*

The component is still named rustfmt-preview. Weird, I thought it was renamed to rustfmt stable (and it is on my Windows system)

Then I suppose there is a "bug" somewhere, because distinctly tells me to install "rustfmt"

"error: 'cargo-fmt' is not installed for the toolchain 'nightly-x86_64-apple-darwin' \n To install, run `rustup component add rustfmt`"

I remember reading an issue that might be related. Let me try to find it...

Rustfmt-preview isn't available on nightly.

Were you talking about stable initially?

Weren't*

My original goal was nightly, but the same issue was happening on stable and I was under the impression that clippy and rustfmt sometimes drop out of nightly

Your impression is right

krobelus: that doesn't allow me to only override some dependencies and not others

How would I have Rustfmt skip a doctest but not the rest of the documentation?

Can I do something like `/// # #![rustfmt::skip]`?

neachdainn: Have you tried this? `rustup uninstall stable`, `rustup self update`, `rustup install stable`

(for your earlier issue)

Will try it!

And then check the list of components with `rustup component list` to see if it includes rustfmt or rustfmt-preview.

stephaneyfx: That worked with "rustfmt". Thanks!

neachdainn: You're welcome :)

hey all, is there a more advanced criterion reference?

I'm trying to find a canonical way to do a benchmark "with set-up" so to speak

i.e. populate a struct with 1000 things, then see how performant adding 1 item is

Do most mutexes live in ARC's?

Arc and static variables are probably the most common

sometimes I put one inside something that is transitively contained by an `Arc`, instead of directly within the `Arc`

So my CI Rustfmt isn't respecting `format_doc_comments = false` and is attempting to format the code in an insane way. Is there any way to force it to not try and format doctests?

Specifically, this insanity: gitlab.com/neachdainn/nng-rs/-/jobs/160528571

has anyone worked with transforming generic code in proc macros via syn? I'm roughly trying to turn #[my_macro] impl X { fn get<T:Clone>(x: T) -> Res { ... } } into impl<T:Clone> MyTrait<T> for X { type Result = Res; fn get(x: T) -> Res { ... } }

the syntax transformation works, and if I run `cargo expand` on my test I get the output I think it should have

but when compiling, it errors with "cannot find type `T` in this scope" pointing to the `T` in `x: T`

My transformation process for the generics is to clone the `syn::Generics` from the method signature, use `split_for_impl`, and stick the `impl_generics` and `where_generics` into the result using `quote!{ }`

I haven't come up with a minimal example yet since I have so much plumming in the macro crate, but here's some input/output/errors in a gist:

Can a struct pass itself into a thread somehow during spawn?

if a struct method takes 'self' by value it can do anything with itself, including use `self` in a closure passed to thread::spawn

what is the rust equiv of `class Value; class Name : Value; class String : Name; class Symbol : Name; unordered_map<Name, Value>`

compiler wants me to assign Mutex<Option<JoinHandle<Thread>>> rather than <Option<JoinHandle...

My understanding is that we put mutex protected things inside of the mutex itself? Does this include overwriting what that Mutex holds?

silentk, try: *acquired = Some(handle)

GreenJello: funny seeing you here

Hi guys! I'm using VecDeque to collect u8s. I'd like to convert the final product to a String. I see that VecDeque supports IntoIter so I can get an Iter<u8> but I don't see a method that returns Option<String> from an Iter<u8>. Is there a way I can convert between these two types? I know that I can convert to a Vec<u8> and get a string from there but I was hoping to avoid the extra conversion.

jxcl: Collecting into a Vec then converting that into a String shouldn't be too expensive

(The Vec->String conversion should just be a validation pass, no reallocation)

I think there's also a VecDeque method that shuffles data around so you can get a single contigious slice?

ah yes, of course, dequeue doesn't necessary have a contiguous slice by default so it requires conversion into a contiguous data type

that makes sense, thanks Mutabah!

hello

is it possible for trait to have attribute, so the implementator must have that attribute, and trait can use modify that attribute

mib_c27p6u: You mean a field, like `trait Foo { bar: u32; }`?

ywow

yes

that's what I mean

but I'm trying to add it make error, missing `fn`, `type`, or `const`

it isn't possible - traits can only have functions, constants and associated types at the moment

I see

damn

or can I make some generic that have particular field ?

mib_c27p6u: What do you mean by that?

mib_c27p6u, in general, no - the standard solution is to just provide functions which give access to what you want

if a trait has functions `bar() -> &u32` and `bar_mut() -> &mut u32` then you have all the functionality of being able to access a field

* `fn bar(&self) -> &u32` and `fn bar(&mut self) -> &mut u32`

oke, that get set solve it for now

thank you everyone

I have a &[u8] that I'm trying to filter and create a new Vec<u8> from. However when I try to call &[u8].into_iter().filter().collect() I'm getting a vector of references instead. Do I have to explicitly clone the u8s into a vector or is there a simpler solution I'm missing?

.cloned()

^^ you'll need to clone the `u8`s since the `&[u8]` is just a reference to them. Since u8 is Copy data though it won't be costly

Iterator<&T>::cloned() produces an Iterator<T> if T: Clone, which &u8 is

if you don't need to iterate and map though, the `to_vec()` method is probably simpler

nevermind, missed the filter

.cloned() is what I was looking for. Thanks!

I was hoping I wasn't going to have to .map(|&x| x.clone()) lol

since it's Copy, `.map(|&b| b)`

but yeah, `.cloned()` :)

eval: --nightly #![feature(iter_copied)] let _: Vec<u8> = vec![&5_u8].into_iter().copied().collect(); // and one day, this

does that take advantage of the Copy trait for some performance gain?

If the underlying type was Copy there is no difference between cloned() and copied()

well, unless someone has manually implemented Clone in some strange way

The (auto-derived) Clone impl of a Copy type just forwards to the Copy impl, ie fn clone(&self) -> Self { *self }

so why add the extra method?

Right, but if they impled Clone manually for a Copy type then they're asking for trouble. There's even a clippy lint for it

jxcl: To ensure that it only works for Copy types, not Clone types

ah, duh

(Advent of Code day 5 spoilers) github.com/jxcl/aoc_2018/blob/master/day05/src/main.rs this is what y'all have been helping me with btw. I'm pretty happy with this solution

play.rust-lang.org/?version=stable&…st=7a3905fca91b15a95d8fc42cf68310f6 i broke it

bug report!

ICE ICE baby

How does that even happen?

I guessing there's an error and the diagnostic output is trying to slice the string in the wrong place

pub use $mod_name; is illegal there, and it actually fails in rustc_resolve::Resolver::report_conflict

done rust-lang/rust #58417

Neat

Is there a slice method like find_mut but with another name that I can't find? or is using position() and get_mut() really the right way?

What do you want to do exactly?

I think .iter_mut().find() would be the same as .iter().position() and .get_mut()

Trangar: yeah that worked, dah.

"trait MyTrait : OtherTrait + 'static {}" → what is the meaning of a 'static lifetime here?

ah ok we cannot implement it for structs with a non-static lifetime

impl<'a> MyTrait for MyStruct<'a> {} does not compile

rom: I can't explain why but this post seems to explain it well users.rust-lang.org/t/why-does-thre…-lifetime-for-generic-bounds/4541/2

Trangar, thx

hi folks

i have a quick question

i have a line of code that looks like this:

self.half_edge_mut(self.half_edge(b_onext).unwrap().sym).unwrap().lnext = a

half_edge_mut is a getter like function that returns an Option<&mut HalfEdge>, half_edge returns a Option<&HalfEdge>

this code works fine as it is

now i tried to do:

self[self[b_onext].sym].lnext = a;

this is essentially the same code, except i've used the Index trait to forward to half_edge/half_edge_mut

but now the borrow checker complains that i cannot borrow self mutably in the outer use, because its already borrowed immutably in the inner use

fair enough, but then why did it work in the first case?

.unwrap() doesn't return a reference, but self[b_onext] does

So .unwrap() returns T, which doesn't borrow self, but self[b_onext] returns &T

Trangar: The unwrap is of a &T

right

The easiest thing you can do is say `let index: T = self[b_onext].sym; self[index].lnext = a;"

so theres still a reference

I think the second case doesn't work because the borrowck feature that makes the first one work doesn't apply to indexing... for some reason

Tranger: yeah, that will fix my problem. im mainly trying to understand why the first *is* allowed.

I think rustc generally gets a bit confused with onelines and borrow checking

Could this be a limit of how NLLs work?

Mutabah: thats... weird

(strange, I'd expect that NLL borrowcheck would be working on the MIR, which is after custom operators are expanded)

Kinnison: this is on stable, so im assuming NLL doesnt factor in here?

ejpbruel: i thought NLL was stable now

is it?

then im even more confused :D

so possibly NLL is what makes the first case work, but somehow not the second?

1.31

I wonder if it's because index arguments are a lower execution priority than function arguments

It's possible. Niko did ask for minimal use-cases where it fails to work in unexpected ways, so I imagine a well composed github issue would be well received

Kinnison: whats the proper place to open these issues?

ejpbruel: I'd guess github.com/rust-lang/rust

Kinnison: ill file an issue!

why does this overflow the stack if it's boxed? play.rust-lang.org/?version=stable&…st=fe0b52290966e8add1160c81755ed4ae

Kingsquee: It overflows the stack if not boxed too

Mutabah, I'm aware

but if it's not allocated on the stack why would it overflow the stack

box == heap alloc, to my understanding

The starting value is located on the stack, then moved into the heap

wait what

it's moved

ai yai yai

Yes.

Kingsquee: play.rust-lang.org/?version=nightly…st=aec777c54e9a2a07ba10f9bc68ef52c5

paradoxspiral, I thought box syntax was just sugar

Box has always been a bit magical

Kingsquee: Vec::with_capacity(n), followed by .resize(n, 0) might be you best bet

`box foo` syntax allocates memory, then tries to write straigth into that (instead of making the value on the stack)

But, there's some underlying limitations to creating arbitary objects with `box`

Kinnison, I'm actually making an abominably large struct, just used the array to test

aah :/

(in-place-expr would've solved this for the general case including boxes, but it was unreliable so it was removed)

I guess some shenanigans with ptr::write might work

Arnavion, 'unreliable'?

It didn't always do its job in unoptimized builds

Kingsquee: Well, `box foo` is effectively `{ let b = allocate(); ptr::write(b, foo); Box::from_raw(b) }`

which defeated its purpsoe

because llvm?

Mutabah, yeah, it's the 'allocate' part that I'm a little perplexed on right now

is there a heap::allocate hiding somewhere

std::alloc::System or whatever it's called

oh yeahhh doc.rust-lang.org/std/alloc/fn.alloc.html

nice, thanks

doc.rust-lang.org/std/alloc/struct.System.html Indeed

Huh, didn't realize GlobalAlloc had been stabilized but regular Alloc had not

Hi guys! Anyone using 'rodio' in rust for audio playback? I want to make an equalizer but i don't know how am i supposed to take the samples while the audio is playing

i've opened an issue for the lifetime issue i mentioned earlier:

Is there a rust diacritics-aware crate for searching strings?

Will nll handle `v.into_iter().map(|x| (x, do_something(&x)))`? Right now the compiler complains about x being moved before being referenced.

user64: Use {~crate unicode-normalization} to normalize the input and output to NFC, then substring

( docs.rs/unicode-normalization/*/unicode_normalization )

Arnavion: thanks.

can you use gtk-rs to create a MenuModel? I don't see a way to construct one

trying to derive Deserialize on a struct, I get this error: bpaste.net/show/d37355d8834a

How much does each push to a rust-lang/rust's pull request cost in terms of CPU time? Is it appropriate to rely on auto checking and avoid lengthy local `x.py build` for small pull requests?

is there a way to disable default-features for implicit dependencies?

tazjin, "Implicit" means "transitive"?

yes

oh just had to remove the trait bounds

tazjin, Does adding them as direct dependencies with `default-features = false` work?

yes, it does - but I'm wondering if there's some other way to do that

tazjin, Make intermediate dependencies re-export necessary features and specify `default-features = false` themselves.

tazjin, Like with clap and structopt. Structopt's default implies clap's default.

concretely in this case, some of my dependencies use some of the async ecosystem, where eventually some crates depend on obscure things like support crates for fuchsia

but I don't use any of the async dependencies directly and it seems like these features aren't propagated all the way through

explicit deps it is, I suppose :) thanks _Vi

hey

hey

I just checked and found out that core::intrinsics::type_id is stable over different compilations somehow. can I assume that this is really the case?

madalynn: docs for me say it's consistent across /crates/, but not across /compilations/

yeah okay fair enough

the problem is I need a way to extract a unique identifier (could also be a string) for a given type that is stable over crates/compilations/compilers.

would be nice if core::intrinsics::type_name had these guarantees

why do you need that?

That seems difficult even in theory (see: the Ship of Theseus).

(s,S,s,)

i want to build a protocol on top of that guarantee. seems like I have to roll my own to keep it stable.

it is mainly about function signatures.

as long as the function signatures stay the same I want the same unique identifier

The best approach is probably to ask the user to define a unique UUID explicitly somehow.

Or something like that.

I don't think there's a good way to do it otherwise.

hmmm

Oh that's easy then.

do proc-macros on functions get the absolute path?

…well. It's easy if you can get a type -> id mapping with that property.

Moongoodboy{K}: if I have something that is unique and stable I can always hash it to get an id

Then you just hash something like "fn({:arg_id[0]}, {:arg_id[1]}, ..) -> {:ret_id}"

…although those won't actually be unique(!).

Moongoodboy{K}: yeah that is basically what I planned to do

Moongoodboy{K}: why won't these be unique?

okay, they are unique if you don't assume hash collissions

hash collissions are okay and I just assume they do not happen for now

impl Foo { fn bar(&self) -> Self { .. } fn baz(&self) -> Self { .. } } // these two methods have the same signature, so will have the same id under your scheme

that's why you also need the absolute path

oh okay there you go

if proc-macros on functions do get the absolute path it'd be easy, then you can just hash the signature

hash "fn {:path}({:arg_id[0]}, {:arg_id[1]}, ..) -> {:ret_id}"

What about aliases and reexports though?

true

so you then need to canonicalize, which makes it much much harder :P

Mmm

proc macros with module system access when? :(

doc.rust-lang.org/std/any/struct.TypeId.html seems perfect besides it being opaque :D

Moongoodboy{K}: two equal signatures having the same id is what I want

Oh. Maybe you could use the hash of that.

Moongoodboy{K}: as far as I saw there is no Hash impl for it

oh damn there is

this could be interesting

i need to know if its type_id is stable across compilations and compilers

…wait a sec. :P

<paradoxspiral> why do you need that?

yeah i'm still not convinced^^

madalynn: nope doc.rust-lang.org/src/core/any.rs.html#463

but what does "globally" mean here? "A `TypeId` represents a globally unique identifier for a type."

probably means across all crates in this compilation?

but yeah cannot use it then

Moongoodboy{K}: yeah maybe

but coming back to core::intrinsics::type_name it should actually stay the same over crates, compilations and even compilers and should only change if the name of a type changes which is assumed to never happen

so if I do not care about hash collissions I should be fine using it

don't rely on implementation details

play.rust-lang.org/?version=stable&…st=bce1cc7207dd1570edce06f0e08160a0 is this UB?

can you explain what is an implementation detail for a type name?

since I have a &mut to X and a & to X

madalynn: docs don't say it's fully-qualified though

oh, type_name. read _id

it is fully qualified as far as my tests go

but yeah it is not specified to be

that's ttrue

j_ey: You modify the static while something is holding a reference to it. That sounds very dragon-waking to me

References fully expect to not be mutated out from under.

Moongoodboy{K}: yeah it's..not great

j_ey: yeah I'm just gonna go ahead and assert that this wakes the dragon

oh well, it's code I was writing for a friend, not my dragon :D

(but really, just gonna suggest he uses a get_X function to do the unsafe/unwrap of a static mut Option<X>)

j_ey: make sure that function is marked unsafe

hmmm

maybe there is a nicer solution overall, but I havent thought of it yet

well, what is this static for?

it's a global so they dont have to pass it around everywhere / clone this Rc theyre using

j_ey: lazy-static and RwLock?

lazy_static won't work because of the way it has to be initialised

You can make it an Option<RwLock<RealFoo>>

then you end up unwrapping everywhere

Yes

Which makes sense, what happens when you have a #[test] function that calls X.foo() ?

wait like half the point of lazy_static!{} is to avoid Option for this stuff

^

with lazy_static you can just give a non-const fn as an initializer

I think they want it to be initialized with data that's available in fn main

^

j_ey: I've done it before with unions, but honestly I'd just take the Option<RwLock<T>> route

Im going to see if they can rewrite it so that the code is called from inside a lazy_static function

It's bitten me more than the overhead of typing .unwrap()

You could initialize it in the lazy_static and update the values from main

Basically like you're doing in that example

j_ey: so the static is only initialized once in fn main, and not later changed?

I changed the example a bit

I actually got a bit confused when I first wrote the example. the Foo struct is there just to deref to the static

j_ey: play.rust-lang.org/?version=stable&…st=68a2e87d6edaa9df11fe6d0cc907adb9

j_ey: so does the value need to be changed after it's initialized?

paradoxspiral: no, i dont think so

Trangar: thanks, will show that to them too

That's the safe way of doing it

then this works play.rust-lang.org/?version=stable&…st=4ef2a7aadf10d2420b7479d79d677e80

Your unsafe way might work, but it might also break horribly and eat your family pet

hm

also what i've done in a similar situation (a global once initialized Config) is just move the code out of main into the lazy_static initializer, no need for that workaround

Im not sure if that can work for them, but I suppose they will give it a try

Hi, I have rust setup on both my laptop and on my android phone via termux. I am looking for an IDE similar to codiad because I can't seem to get codiad to work on my phone. It works the first time and then I can't figure out how to start it again. What can I use instead? Anyone know?

You have rust set up on your phone?

I might have to try that...

imagine the compile times :p

Can't be worse than my current build server :D

Pretty sure my phone has more CPU

ah, the warmth of rls in my pocket

lol

pub const CSW_RESERVED: u8 = 0x01000000; // rust does not complain aboutthis?

eval: pub const CSW_RESERVED: u8 = 0x01000000;

It didn't always IIRC, maybe you're on an older rust version Yatekii?

It's an error in Rust 2018 afaik

Alexendoo: pretty recent

panicbit: why you no make eval put errors before wafningst

maybe it's not at that pass yet then

panicbit: also gotta fix the ?edition thing (eval clearly submitted that code with edition 2018, but the link it posted doesn't have ?edition and thus defaults to 2015)

Moongoodboy{K}: It's not trivial to do so

Moongoodboy{K}: I've been requested the playground to support json compiler output

to allow me to do the reordering

ah, okay.

words.

Yeah, the edition stuff needs fixing

Now that I'm sick and can't go to work, I may actually find the time

Aww.

thank

....waiting for file lock on build directory

...5 mins later, still waiting

*groan*

I am attempting to do some custom pretty-ish printing. Currently I am using `{:0>#2}` but I want that 2 to be dynamic (I have a u32 local I want the width to be), how can I do this? Do I have to use named print/format args?

When a function generic over T requires many constraints on T, we can group them under the same Trait

but how to do it in this case: play.rust-lang.org/?version=stable&…st=b9d2cbf0b8f6f3cd81f79e28d229ca26

rom: play.rust-lang.org/?version=stable&…st=a441fd37036b010e4ff56ac9858e7a72

rom: This is similar to the dual From/Into from std

rom: The idea is to swap the type parameter and Self

ok, this works, but I would have liked a version using conv: the fact that i32 is Conv<T> is an "intrinsic" property of my trait, so the client should not care about

even with: "pub trait Constraints: Sized + Conv<i32> where i32: Conv<Self> {}", if in my function I use T: Constraints, it does not infer that i32: Conv<T>

Given a Result<usize, usize>, how to "unwrap" its value without caring if it is Ok or Err?

blink: r.unwrap_or_else(|x| x)

stephaneyfx: Lol! Thanks =)

wut

why would you want that?

Phrohdoh: (Just a wild guess) Maybe to handle the result of doc.rust-lang.org/std/primitive.slice.html#method.binary_search?

But wouldn't you end up with the exact same result type?

You'd end up with an usize, not a Result

Ah ok

They don't care because it is likely the same value

for both T and E

its still not possible to impl trait for long arrays?

I have a function that creates a reqwest client and passes it to a function which uses the client and the response. I want to test those functions. I'm unsure what the best way to mock reqwest is.

jonimake: is there actually a cargo or rustc instance trying to do something in that directory?

eval: format!("{:0>#len$}", 42, len = 7)

Phrohdoh: ^

Thanks I'll give that a go :)

nifker: well, you can `impl<T> Foo for [T; 4096]`

but you can't yet `impl<T, const N: usize> Foo for [T; N]`

Moongoodboy{K}: seems like many crate dont have this automatically implemented

Don't have what automatically implemented?

[T; 0] to [T; N]

Can I "attach" a trait to a struct that already directly implements the same interface without redefining the implementation?

ldiamond1: I guess it'd be better to move the code out in the trait entirely?

heio, anybody here ?

dftxbs3e: it's not my code, it's reqwest

They don't define traits for everything so I'm stuck defining it

ldiamond1: ah ok, well I don't think so that you can. It makes more sense and it's more consistent to move the code in the trait implementation. Try a PR! I'm sure they'll love it.

In the mean time, your dependency can be a git branch of yours\

ldiamond1: not at the language level, but if the names and signatures are really the same, you can use a macro to trivially implement (such a macro might already exist)

…and, yeah, for the mid to long term, actually implement the trait upstream

Or am I doing it wrong?

I use reqwest to make HTTP requests. I want to test my code against a mock.

My idea was to create a mock that matches what I use, make it implement the same traits and simply replace it

hey, how likely is it that Rust's compile-time evaluation feature is seeing significant progress this year?

Anyone good with serde?

I don't understand why serializing an Option doesn't work here: gist.github.com/vext01/838d9e589363327500e4bce3b32a4c74

serializing without the Option wrapping, as shown in commented lines, works

Edd-M: does rmp support nulls?

msmorgan: I assumed it did, but I guess not?

Edd-M: what sort of error do you get?

maybe it just doesn't support top-level nulls

but nulls inside of a structure would be okay

Ok, well I could do with top level option

Is there a better serialised format?

Edd-M: for what purpose?

msmorgan: stuffing things into an ELF section, eventuallly

btw, i tried pusing the Option inside another struct, the outcome is the same

struct Packet(Option<MetaData>)

Edd-M: it appears to support it

Note that my example uses only Some

this is werid

any ideas if Rust's const-eval functionality is moving a lot in 2019?

msmorgan: 3Hren/msgpack-rust #183

is there a hard reason for why lifetime elision in function definitions doesn't extend to 'where' clauses, or is that just something that hasn't been implemented yet?

Edd-M: that would do it

looks like it's not released yet

no

which is irritating

you could vendor the package in the meantime

or use a git version

or use a git hash

yeah

e.g. 'fn foo(&self) where &Self: IntoIterator' won't compile.

msmorgan: not sure I can use git

egregium: why not implement the trait for &'a Self

he's got several crates in the one repo

Edd-M: that works

you indicate it's in that repo and it finds the crate from the cargo workspace of that repo

is there a convention for taking an Arc by reference or by value? play.rust-lang.org/?version=stable&…st=3fe26f432b84e89da7f12e521a0e6afb

msmorgan: i see, thanks

msmorgan: because that's not the only method.

kora: Most of the time they're taken by value

in my experience

msmorgan: works

thankyou for your help :)

msmorgan: so that would make the cloning explicit

egregium: for some reason [E0637] doesn't exist in the error index

egregium: but I assume that when using a reference as a type, you need to explicitly name a lifetime for that reference

What's a good primitive for some kind of shared event in Rust? Thinking along the lines of something with set and unset API

there's a typo in the E0716 compiler error message, the word value is missing in two places: play.rust-lang.org/?version=nightly…st=ce3e9ba20c4a65574387f66aa43f84f2

digital: perhaps they're using "temporary" as a noun

seems jargony though

I think it's pretty standard compiler/language jargon, though

if it's a noun then it should always be a noun, in which case there are two "values" too much

fair point

you a copy editor?

e.g. gcc.gnu.org/bugzilla/show_bug.cgi?id=2350

I'm not a copy editor

digital: in the error index the first use of the noun temporary is bolded

Anyone here use rendy yet? I'm trying to get it running but their examples don't seem to work

msmorgan: hm okay

how can i make a hashmap that accepts two different members of an enum as the key

snek: like, either or?

msmorgan: so i'm making an interpreted language

i'd like the keys of objects to be either a string type or a symbol type

right now they're only strings

oh I see

but not simply any type at all

which i get by lowering my Value::String(String) to just String

could you make a MapKey enum?

i can't use Value itself as the key because its not hashable

and lower to that?

how would that play with my Value enum

the same way the present string behavior does, right?

so there's just be an extra layer of indirection for my string and symbol types

just have a way to try to convert to a MapKey

oh have a separate type hmm

yeah, enum MapKey { Symbol(Symbol), String(String) }

and implement hash for that (or derive it)

what is Symbol(Symbol) though

Symbol itself is a Value

so that would be circular

don't you have a Value::Symbol(Symbol) variant?

or is it Value::Symbol(String)

or something

Value::Symbol(String)

okay then use Symbol(String) in MapKey

where String is a symbol's "descriotion"

description*

isn't there supposed to be some sort of opaque information in a symbol?

isn't that just being a symbol

in JS, you could have multiple symbols with the same description, but they wouldn't be considered equal

isn't constructing the symbol variant already doing that in rust

nope

why the FUCK does rust have a lifetime on it then

huh?

calm down

like

`enum X { Y }`

using `X::Y` gives me something with a lifetime

yes, values have lifetimes

lifetimes are erased at runtime

so you can't compare lifetimes

no i mean

if its just some thing that represents a lifetime

enum member*

downleveled to a number or something at compile time

why does it have a lifetime

because values have lifetimes

for the purposes of the borrow checker et cetera

can you borrow an i32

yes you can

now that's messed up

Well, stop using rust then snek

lol

but i'm trying to learn rust

is there a good plotting library out there?

read the book instead of jumping in with half-baked ideas

i've read lots of the book

i can see that

the book is useful for people who already know rust

not for those two don't

now you might know enough to comprehend this chapter better

so what should i do to make my symbols unique

add additional data to them

some sort of identifier

increment an i64 or something?

that would work, yeah

if you're incrementing though, u64 would be better ;)

indeed

unless the language has special symbols and you want to give them negative IDs for some reason

i'm just used to calling everything not a float an integer from wasm

that's why I said Value::Symbol(Symbol) at first

because I assumed that the Symbol variant would contain a Symbol struct

snek: one of the reasons you might have had a misunderstanding about borrowing i32s and such, is that they're just a bit pattern

every i32 that's 00101 is the same as every other

right?

well i'm just more used to thinking about things on the stack, like random numbers, as not having any lifetime

Rust has a trait that specifies this, called Copy. if a type implements Copy, the compiler treats it a little differently. instead of transferring ownership ("moving") when a value is passed without a borrow, it just makes a new copy of it

since all you need to do is copy the bits

yeah i saw that

that's why i32 seems to behave differently than most user-defined types

its an interesting way to describe the actual behavior of numbers though

unless they actually are all heap allocated

which i hope isn't the case

almost everything in rust is stack allocated, except memory that has to be dynamic

how do I say an associated type has to impl X?

Yatekii: type Foo: X;

oh that was easy lol

thx

for instance a Vec stores its members in the heap since you won't know how many there are at compile time

but a program like `fn main() { let v = vec![1, 2, 3]; println!("{:?}", v); }`

will store the other information about v in the stack

including its length, current capacity, and pointer to the heap storage

yeah that seems normal

depends on the language

it wouldn't be normal for Java

java isn't a normal language

lol define normal

not java or brainfuck

That's not a very productive side-track if you want to get on with the real problem :)

java is brainfuck with curly braces

see viny gets it

okay C# then, reference types are allocated on the heap

and List<T> is a reference type

QED

lol

isn't c# also the thing with linq

qed

yeah, linq syntax is weird

but the underlying methods are pretty standard

beautiful static SYMBOL_COUNTER

just transformers for iterators

snek: are you using an AtomicUsize for that?

no

why doesn't a panic require a semicolon?

kora: if it's the last statement in your function

kora: it never returns and the compiler knows it, so it coerces the 'return type' into any type it needs to be.

yup

same thing with unreachable!() and unimplemented!()

I see

and any function call to a function with the return type '!'.

is there a way to define implicit conversions between types

i tried to define a from trait but that didn't work implicitly

there's Deref

but not quite the same

but not in general, no

snek: rust tends to avoid implicit conversions except for some special cases.

the From trait is the typical way to define conversions that you want other generic code to understand, but it's explicit.

is it impossible to safely implement a doubly linked list?

nope, it's quite easy actually

but you have to understand lifetime and RefCell

and then, why would you ? ;-) doc.rust-lang.org/std/collections/struct.LinkedList.html

so one way is owned, and the other way is reference counted?

blank_sl8: yepp ... one way to see it. or RefCell which holds a straigth reference

oh, refcell isn't reference counted, is it

that was rc or something

nope, for linked list you don't need reference count, yoiu know how many things hold it

RefCell allows you to "borrow" dynamically @ runtime

RefCell? How would a node look like?

so if i'm making a data structure (tree-like) that needs nodes to reference their parents, I would typically use a refcell?

yes, one solution. let me dig something out

this one: cglab.ca/~abeinges/blah/too-many-lists/book

you like lists, that shows you how to do lists in rusts in all variants including what yuou ask

funny book as well

the bad safe deque?

uses Rc

yes, that gives you a Rc design

then you understand cglab.ca/~abeinges/blah/too-many-lists/book/fourth-final.html

Is C relevant nowadays?

but the point is not in the solution, point is to erad the journey in the book

hey folks, I am fairly new to rust and using it to build a cli. I am trying to talk to a single sign on service using hyper and getting this error "peer cert is valid, or was ignored if verification disabled". any idea? thanks

that will teach you HOW to preoperly lay out stuff in Rust to be safe while taking the ownership concepts to only the degree complexity you need for Send+Sync+RefCell

curiousernestbri: probably most running code on the planet is C these days

mr_wibble: that doesn't sound like an error message, it sounds like everything went fine.

thats what i thought but its being caught by the ` .map_err` maybe code is wrong

and with reqwest i get mibpaste.com/aOQxaY

hmm the code seems to work in a linux container

negative error codes sounds like windows, so schannel

@seanmonstar I am on a mac though

oh that helps, wasnt finding that error in msdn

i came across some random links with mentions of apple stuff with that error code

"errSSLPeerAuthCompleted"? whys that an error XD

found github.com/kornelski/rust-security-…mework/src/secure_transport.rs#L982

i cant actually comment what that error code is supposed to mean

seanmonstar: IIRC that's used to tell secure transport to stop the handshake at that point and give you back control

if you want to do your own processing of the peer certificate chain or whatever

might be misremembering though

do you know how to get around it @sfackler

it's probably a bug in native-tls

and/or security-framework

we should just keep going when running into that

what triggers it? ive not seen others reporting that error

the server might be requesting a client cert?

since it's an SSO thing

doesnt security-framework interact with keychain? would options in there trigger it?

don't think so: developer.apple.com/documentation/security/errsslpeerauthcompleted

so they have a second status code besides errSecOk to mean errSecOk

can main() in build.rs return Result<(), Box<Error>>, too?

and ExitFailure etc

why not

its just a binary

it can panic!(), too

seanmonstar: ah right, it's returned if you enable break_on_server_auth: kornelski.github.io/rust-security-f…mework/secure_transport.rs.html#188

which you do to iirc handle custom trust roots

so is this intended behavior or something wonky with how apple handles things?

and I guess a follow up is: is it possible to have native-tls use openssl instead of the apple one

it is not

it's a bug in something, either native-tls or security-framework?

one thing to mention and not sure if its related is: i wrote this tool in go before and renegotiation was needed.

ooooh

that's probably it

there's some other API call that we need to ignore that error from probably

does anyone know a short way to test if all elements in a slice are equal?

with iterators and stuff

I was looking at the code and very confused about how this would be breaking in this way some but not all of the time in the handshake :P

mr_wibble: if you wanted, you could try the rustls backend of reqwest

in your Cargo.toml, change to `reqwest = { version = "0.9.9", default-features = false, features = ["rustls-tls"] }`

i feel like i read re-negotiation is a non-goal of rustls tho...

so in the rusttls readme the author says there is no support for Renegotiation.

`The following things are broken, obsolete, badly designed, underspecified, dangerous and/or insane. Rustls does not support:`

ah then nevermind :)

cool that you can do that with cargo though

mr_wibble: I think you'll want to file a bug on security-framework - it probably needs to internally ignore that error coming out of read or write or something like that

patapon: fold() could probably do it reasonably neatly.

is the history of this chat saved somewhere?

mr_wibble: it's in the topic.

Logs mozilla.logbot.info/rust

answered my question mozilla.logbot.info/rust

thanks

@seanmonstar @sfackler let me know what i can do to help debug

mr_wibble: best would be to file an issue on the security-framework repo, including the error and that its using renegotiation

if theres a way to reproduce it without needing any secrets from you, even better

I have an enum that implements Display... how can I impl serde::Deserialize for it, where it serializes to what format!("{}", self) would return?

GreenJello: docs.rs/serde_plain/0.3.0/serde_pla….derive_serialize_from_display.html

I got my thoughts mixed up, but this looks like what I need, thanks!

kyren: Has anyone done any proc macro binding nonsense for rlua yet?

lpg: not that's up-to-date, it's actually on my near term TODO list

I need a value to be consumed and allowed to die. Can I just pass it into a function to kill it?

drop can do that

also amazing work on rlua, this is fantastic

lpg: I'm not sure exactly what to call the trait, because people seem to get easily confused about conversion between structs <-> tables and structs <-> userdata, I'm almost certain once I write it to get questions about how to do proc-macro userdata conversion, which I'm not sure is even possible or sensible

lpg: oh thanks!

lpg: is it similar to your bindings system for Lua 5.1?

kyren: there's no semblance of safety in it and the bindings are mostly giant C macro invocations, but it's fairly convenient at least

silentk: if you're not getting the value as a function argument you can also just wrap the code that creates and uses it in a { } block and it will be destroyed at the end of it.

though that isn't always feasible when you have other variables declared after it that depends on the value.

lpg: I'm always interested in what other people have done because there are a bunch of really hard decisions that you have to make when writing language bindings in Rust, and I'm not convinced all of my decisions in rlua are the right ones, especially around ToLua / FromLua trait design and function types

lpg: if you wanted to make it safe, you might have an easier time because Lua 5.1 doesn't have __gc metamethods, right?

kyren: it does have __gc, but only for userdata, and also we turned them off because it was a huge sandbox escape hatch lol

kyren: the ToLuaMulti implementation for all the tuples in rlua made several people laugh nervously that I showed, so that was awesome

right, I forgot it was available but only for userdata

lpg: are they bad haha?

I'm currently working on a PR to rustup. `cargo build` works but it doesn't produce an actual rustup binary, only a rustup-init binary. I'm looking through .travis.yml and others to try to see how to produce the rustup binary, but no luck so far. Does anyone know how to build the rustup binary?

kyren: I'm not sure how else you'd solve the problem, heh

me neither, all of rlua was a goddamn bitch and a half

Lua projects I've worked on that specialize arg length/return length usually go out to 5-6, I think that's the limit on LÖVE's event loop stuff

naftulikay: hm, what about cargo build rustup

build doesn't take an argument? it complains that it found an argument it didn't expect

what about cargo run rustup

kyren: You mentioned proc-macro driven userdata stuff being difficult/not possible, that's what I was imagining to try, what issues do you see with it?

nope, same thing

`Found argument 'rustup' which wasn't expected, or isn't valid in this context`

I'll ask on users.rust-lang.org

lpg: sorry I was being a bit vague, I'm sure it's possible (and even pretty easy) to do a proc-macro for table conversion, and I'm sure it's possible but kind of hard to do a set of proc-macros for userdata + methods

the fact that the struct def + impl block are separate blocks is pretty inconvenient

lpg: but I've been asked for stuff that's... I guess not impossible but reeally magical and problematic before, like __index based access to userdata *fields*, which okay I guess that also *might* be possible, but it can kind of get insane

I haven't really actually thought about it extremely deeply yet

and a lot of the problems are the same problems that wasm-bindgen is solving

it's not that bad if you construct a new userdata wrapper around the type for every __index :D

at the cost of making hashing on [userdata.x] really inconsistent and scary, but that's the tradeoff we made

I gueesssssss but they might not even be Clone

still looking for a way to build the rustup binary: users.rust-lang.org/t/building-the-rustup-binary/25256

naftulikay: where in the crate is the source code for it (the main() function) ?

kyren: all of our types are either referentially consistent and mutable (instances) or an immutable value (everything else), which is handy

naftulikay: do you have rustup-cli

?

oh sfackler replied on the web

yes, this solves my problem 👍

where is the `ref` keyword in a `match` statement documented?

for use like this play.rust-lang.org/?version=stable&…st=0fc329c766cd30c07f246165495ddb29

blank_sl8: reference-level docs are at doc.rust-lang.org/reference/pattern…l?highlight=ref#identifier-patterns

blank_sl8: And the book calls them... "legacy patterns" doc.rust-lang.org/book/ch18-03-patt…tml#legacy-patterns-ref-and-ref-mut

so, is there a more up-to-date way i could have written teh playground?

without using .map or anything

Some(string_cheese) without `ref mut` appears to work

yeah, just leave out ref mut

so it magically detects that it doesn't need to take ownership of string_cheese?

Yes

will that ever fail and make ref/ref mut necessary?

yeah, you don't need the ref mut here

you want to _move into_ the string inside

I'm mildly astonished you don't need a mut though and it inherits the &mut

blank_sl8: In specific circumstances maybe, but there was a big effort to make ref/ref mut unnecessary in patterns

My gist linked above works. Curious if it

ok, i'll try to avoid it then. Thanks!

blank_sl8: It's all explained in github.com/rust-lang/rfcs/blob/master/text/2005-match-ergonomics.md

curius if if looks awful at first glance

aha, when you add mut it moves in and I get the xpected "cannot move out"

blank_sl8: Just in case you want to know more

it seems to infer the ref mut on the pattern now. That's new ;-)

i think i'll read that a bit, i'm reading some article someone linked about linked lists and they are using ref a lot

the new 'smart' ref-less patterns are really confusing.

egregium: well, if they really work ;-)

blank_sl8: basically, simple rule, if compiler throws at you error[E0507]: cannot move out of borrowed content

you need ref ;-)

it's not that new, by the way, it's a couple of months old.

i dunno, having rustc error on you because you forgot a `ref` was pretty annoying

ted: but it forced you to think what the hell you're trying to do ;-)

blank_sl8: it's not magic, it just propagates the &mut into the inner bindings

eh

there are enough places where you have to think about ownership where it actually matters :)

ted: one of the biggest performance killers is implicit Clone and ending up moving into stuff that forfces Copy when you really need a ref

ted: agree here ;-) I'm not unhappy, I just say it's new ;-)

sorry, I mean "implicit Copy"

yeah, that's fair

"segmentation fault" induces the most thinking about what you are doing imo

which rust never gives you ;-)

as in 'what am i doing with my life?'

'why aren't i using only safe rust?'

egregium: yepp, as in, why am I still doing C bean counting if I can be lazy and let compil.er in rust do it ;-)

egregium: Rust is for the good programmers beacuswe all good programmers are "lazy" and try to not do beanc counting but work on interesting stuff that computers cannot do for them ;-)

What is the memory layout of enums? Does the discriminant always appear first?

hah

npmccallum: not defined, as far as i know.

npmccallum: Unspecified

npmccallum: any data type with repr(rust) (the default) is unspecified

npmccallum: the discriminant doesn't even exist as a separate field in some cases.

Option<&Foo> is the same size as &Foo, for example - the forbidden 0 value for the reference is used to encode 'None'.

Can I use something like repr(C) to get a defined layout?

For enums whose variants don't have data, yes

or repr(u8) etc to get a certain size.

What problem are you trying to solve

What I really want is repr(u32) where the layout is u32 first and data afterwards.

Why do you need that

npmccallum: there's an RFC for that: rust-lang.github.io/rfcs/2195-really-tagged-unions.html

but i don't know if you can actually use that yet?

Arnavion: I'm trying to match the memory layout of data coming from firmware.

there might be some way to actually do that

For FFI you cannot have enums with data

Gankro wrote that rfc, you might ask them

Make a struct that has a repr(u32) enum and a union of the fields after it

ok

npmccallum: do you want the payload to be aligned as if its struct { u32, field1, field2... } or struct { u32, struct { field1, field2, ... } }

The latter.

I assume I can use an attribute to align this type to a page boundary?

there is repr(align), but I cant remember all the detais

npmccallum: github.com/eqrion/cbindgen/blob/master/tests/rust/enum.rs#L46-L51

npmccallum: is ABI-identical to github.com/eqrion/cbindgen/blob/mas…tests/expectations/enum.cpp#L59-L82

which I believe is what you want

"If the enum has fields, the effect is similar to the effect of repr(C) in that there is a defined layout of the type."

about repr(u*)

Gankro: They said they want tag + union-of-fields, not union of tags+fields, so I think they want G

oh oops, misread :)

yes

repr(C, u32) is what you want

#[repr(align=X)] does alignment

this seems to suggest that repr(C, u32) would be the same as repr(C) if it has fields

j_ey: I wrote the RFC, the compiler impl, and mantain the docs you linked :)

Can someone help me understand the matching in this code? pastebin.com/raw/bqYbyMbv

plain repr(C) is sugar for repr(C, "whatever an enum is sized to be in C on your target hopefully")

Am I able to detect an invalid enum value in the case of FFI?

Gankro: no doubt, but I'm trying to understand the text

Particularly, I don;t know what `m if is_yelling(m)` means inside the match bracket.

ksynwa: 'if is_yelling(m)' is an extra check that means that the branch will only be executed if is_yelling(m) returns true.

Gankro: from my reading it doesnt sound like repr(u*) affects the size, if repr(C) is also there

Gankro: tag + union of structs

Gankro: so I want repr(C, u32)?

does Duration support an infinite time?

egregium: is `m` an alias of message.trim() there?

npmccallum: yes, i'm not sure what you mean by "detect"?

ksynwa: 'm' is an identifier pattern that matches anything and names whatever it matched 'm' in the context of that branch.

nifker: doesnt look like it

ksynwa: so in your case it will bind to the return value of message.trim().

egregium: I get it now. Thank you very much.

j_ey: i mean, just look at the cbindgen examples I linked, the different sizes affect the output (and we use those results in firefox)

Gankro: If I have an enum repr(u32) and I pass a reference to it to a FFI function where the FFI function fills in the value, it is possible that the FFI function fills in a value which is not represented in my enum.

Gankro: I'm not sure the best way to handle that situation.

Gankro: sure. I still feel like the docs don't explain that well

npmccallum: sadly it's Undefined Behaviour if they set a bogus value. You can use the equivalent struct-and-union repr while you're not sure if it's properly initialized, do the check, and then cast to the nice enum form afterwards

Gankro: this is a different case

Gankro: I don't have data in the enum in this case.

g2g meeting

npmccallum: i think it doesn't matter whether it's a c-like enum or one with data in it, an invalid value for the discriminant is still undefined behaviour. you'd have to just read it as a u32, check it, and then convert it to the enum type if you want to avoid that.

yes

Is the discriminant value well-defined for enums with data?

(i.e.: starts at zero and increments by one)

npmccallum: it matches the platforms C convention

which for all the ones I know is 0,1,2,...

npmccallum: it's most likely unspecified unless you repr(C) it

if you do, it is

Hmm, for some reason `cargo build -p foo` within a workspace works, but `cargo build -p bar` for another crate in the same workspace fails with "can't find crate for `failure_derive` which `failure` depends on". Both foo and bar depend on failure. Any ideas?

(in practice it's likely the same as the repr(C) specified one because there's no reason for it not to be, at least so long as there is a discriminant at all)

Obviously failure_derive is there in the lockfile, and `find -name '*failure_derive*'` finds files for it under target/debug (from the initial successful build of foo)

Hello

how can I use std::io::set_print on stable rust? I really need it and don't want to be forced to use nighttgly

thank you

you can't

is there a workaround?

this is stable right? doc.rust-lang.org/beta/std/panic/fn.set_hook.html ? there is no equivalent for print?

or it's unstable as well?

panic::set_hook is stable

but I really need the same for stdio

isn't it possible to do it? even if it's unsafe?

can you do it with some hacky to close and redirect fd?

unfortunately I am not under linux I am under wasm

not sure how it works with actuual fd

setting the Write in set_print looks the cleanest to me

Looking at this there is a LOCAL_STDOUT var doc.rust-lang.org/beta/src/std/io/stdio.rs.html is it possible to replace it via unsafe?

no

surely there must be a way?

you could try and alias it via a no_mangled name using the mangled name of that symbol

is this so you can redirect println! to console.log?

yes

but libraries have a hash in it iirc so it would be terrible

talchas: yeah.. I didnt really want to suggest that, but was one of the options I thought of :)

and then just use nightly

how do you do that? I don't even understand what that means

I would prefer not to use nightly, I had issues with nightly

it would be even less stable than nightly, in that it would be guaranteed to break every time you changed rustc version

even on stable I found issues in the compiler for what I was trying to do and had to make a bug report

how do you alias a function? you mean alias the function that println! uses internally?

ignore that suggestion

:(

yes, just dont

isn't it possible to get some pointer somewhere and just replace LOCAL_STDOUT?

I mean create an extern { fn the_mangled_name_for_set_print(args stuff); }

don't actually do this though, yes

Hi, as my rust project is getting bigger, compilation time is shooting up. Only solution which I came across is to divide project into multiple crates, which helped a bit. But problem is everytime, I change something in a crate, all the dependent crates get rebuilt.

and anything else would be equivalently terrible and breaking

Hi folks. What syntactic sugar is there for turning an iterator that yields (String, String) into a HashMap?

thavlik: collect?

but it's not syntax sugar

thavlik: .collect::<HashMap<String, String>>()

hmm is there smth like map() on an iterator that also returns the previous element?

talchas, much appreciated

honestly it seems severely constrained that rust doesn't allow me to do this especially since I really need it

Is there a way to fool its dependent crates that nothing has changed in parent crate, and make them use the latest crate using dynamic linking?

Yatekii, no but you can .peek()

sunset: the point of the unstable features is so that they're not exposed to stable builds

Which of danielkeep.github.io/tlborm/book/mbe-macro-rules.html#captures do I want for to be able to do `Foo(baz)` where `Foo` is a variant of a specific enum? (this macro will only use this single enum type)

> ($start:expr , $end:expr, $tok:stmt) => { SpannedToken::new(ByteIndex($start), ByteIndex($end), Token::$tok) };

> tok!(1, 1, Ident("^foo")),

viny so you say I should first call peek() to get the current one and then next(9 to get the next one?

j_ey: but it's been unstable for years and hasn't changed, and it's being used internally by cargo test

sunset: github.com/DeMille/wasm-glue ?

sunset: it's unstable because it's not clear it should exist at all

oh that looks like it needs nightly

Phrohdoh: it would have to be "$variant:ident($arg:expr)"

ah okay so I'd need multiple to work with data-holding variants and data-less ones

thanks

j_ey: but that means you have to import that macro instead? or it overrides it

eval: enum Foo { Bar } Foo::Bar()

it seems like a valid use case for me sfackler , and other languages I know allow you to do it

eval: enum Foo { Bar } Foo::Bar{}

eval: #[derive(Debug)] enum Foo { Bar } Foo::Bar{}

talchas: worked perfectly, many thanks

Phrohdoh: so you can use the {} syntax for all three types of enum/struct, but not the () syntax

I don't follow

Foo{Bar} ?

sunset: no-one is arguing with that

Phrohdoh: Foo::Bar {} is valid for no args, and Foo::Bar { 0: arg } is valid for a 1-arg tuple variant

but I'm not actually sure this is useful to you, and it's probably easier to just have two macro variants

Right but not for Foo::Bar(baz), right?

yeah the two variants seems to work fine

one for "Bar" and one for "Bar(expr)"

yep

j_ey: it looks like wasm-glue also uses set_print? so it wouldn't work on stable either?

sunset: correct, I followed up with that

sunset: when did you last use nightly?

it's pretty stable usually. and you can find a stable one and just continue to use that

I think it was more than 6 months ago, and my library has been stable since then

I would regret to move it to nightly just becasue of this

maybe you should try push for it or something, to be stabilized

well I don't have my hopes up, I don't have any influence, and that might take months no?

you can try ask on one of the other forums, but I dont think there's a way you can hack this

This exists for years rust-lang/rust #31343

tl;dr which exercise should I give to someone who is convinced that he is The Omnipotent God Of C, and that any language that tries to have memory safety as a design goal is useless?

(I could describe the situation more, but that's the gist)

Coylabe: You can't convince someone with that mindset of anything.

IME

I actually knew a guy (my uni professor) that was so disciplined he could code stuff without compiling and even syntax coloring

They've already decided they know everything and anyone who disagrees is wrong.

he once won a bet by coding I think a 2d game clone, forgot which with the right to compile only twice to check for his errors and won

such people exist Coylabe even if rare

I was thinking of something like "Code a program according to those specifications, then" and see if he makes it or not.

Oh, I'm not saying the possibility is zero! I don't think it's higher than 0.5%, but it's not zero.

evne the woman that made the original nasa moon ship program and such coded most of it on paper first

it is possible Coylabe to write correct programs in C, even without the help of the compiler, but it's much harder to do so, and much error prone

Yes, which is why I'm curious to see if he can do it.

what rules? he can use a compiler as much as he wishes and syntax coloring?

something with asynchronous parallel consumers and producers

and reads a file format

when he's done, run it through a fuzzer

Coylabe: Ask them to build whatever you're building. Free labor! :D

honestly, parsing just about any file format, and running the parser through a fuzzer will break it

as a "challenge" of course :)

not if it's written in Ocaml wpage

sunset: I thought we were talking about a C developer who swore he could write anything safely in C without help from the compiler or language

you can copy a Box, right? But then when is the memory deallocated?

or can there be only one owner of a Box?

you cant copy a Box

I think you can with to_raw_ptr or how it's called

ah Box::clone copies the contents?

clones

ok thanks

I forgot a bit the apis, but you can do many things if you convert rust stuff to ptrs

it's pretty straightforward

Can I get `cargo test` to print out the `ignore` reason?

(for each ignored test)

in a library/crate, I will use failure I guess. But is it ok to bail!("some textual error message") or should I aim to have enums only?

j_ey: can't you make a new rust release where it's possible to use the feautures I need from rust stable?

...wat

aka nightly

or add levels to experimental feautures? like somes can be used from stable but are discouraged? like they work but can dissapear vs completely experimental

j_ey: cmon release new rust ;)

sunset: that level *is nightly*

there is a difference between something that might disssapear as in api not stable vs feauture not stable

set_print has been the same for 3 years basiclaly, I should be able to use it

sunset: go complain on the issue

Phrohdoh: there is a difference in stability or safety between set_print that is used by cargo test, hasn't changed for years, and might dissapear vs a really experimental feature

I should be able to use once

Not with the way Rust is released currently.

go make an rfc for it

^

can't someone add a new field to unstable to say like level of unstableness? and allow a low level to be used tin stable with a warning? such as set_print for example?

Someone *could* sure.

when I mean someone could I meant couldn't like j_ey do it?

But it isn't just adding a new line and calling it done.

but it requires rfc etc

sunset: why me lol

well removed the #unstable is just one commit

sunset: *you* could do it

I am not really familiar with the rust code, it might take me years to do it or something

rust code is scary

I mean I could just remove the #unstable sure, but doing the other suggestion might take too much time

sunset: Doing things correctly takes time.

also last time I looked at the rust code there were parts that looked really cryptic, I don't think it's well written

rust will definitely get in your way though

the only question is if you value that

I am really upset, everytime I try to do something in rust things get in my way, this week was full of frustrations

same

sunset: It'll be like that for a long time, IME.

it's been more than 5 days I've been waiting for someone to fix the compiler bug I've found and nobody did

can you do it j_ey ?

no

being able to store things at known offsets in allocated memory and cast around

i miss that

are we being trolled?

j_ey: can you at least take a look at it?

sunset: Why have you latched on to j_ey?

sunset: I dont work on the rust compiler

who works on the rust compiler? do you Phrohdoh ?

Nope.

:(

but you realise this is an open source compiler, 5 day isn't *that* long for a bug to be open

but it's being supported by Mozilla, actual employees work on it

There are other priorities I'm sure.

Just because a bug is opened doesn't mean people drop everything and fix it.

so it might never be fixed?

sunset: what was the github issue number?

can you fix it snek ?

that was 3 days ago

sunset: people are *actively* commenting on it

and people have been commenting on it

i started using rust a week ago

oh? for some reason I thought it was 5 days

time goes fast when you're having fun :)

sunset: give it some time, nothing is more annoying than people being upset when oss contributors don't move fast enough

it wasn't much fun for me, I had to stash my changed cause I couldn't continue

you could always fix it yourself

unfortunately all my 3 ideas that I have been thinking about have been shut down for various reasons

I mean, what you have won't compile

mhm I understand

the effort I'd have to put into understanding sufficiently and try to fix it would be collosal

the fact that you're getting an ICE rather than a proper error message is a bug obviously, but I think the correct code would compile

It would most likely take much more time than waiting for someone to fix it

sunset: everyone starts somewhere.

sunset: did you read the comments and what talchas just said?

i learned c++ by contributing to node.js core

talchas: wouldn't compile? why not?

It has been made clear that people are commenting on it (and thus looking at it).

sunset: you have Fn() -> SomeTrait, aka Fn() -> dyn SomeTrait

you can't return an unsized type

so it's impossible to do that at all in rust?

can I return a reference instead or something?

To return an unsized type, yes.

and yeah, the simplified version posted on the bug compiles if that's fixed play.rust-lang.org/?version=stable&…st=56be12fcfe701c0079690d48c4e1e1ff

most of the time it would need to be a Box<dyn Trait> rather than a reference

but yes

sunset: you can box it for example. Fn() -> Box<SomeTrait>

and can I take stuff from the Box?

in my case I need to call stuff on the box

you can use Box<SomeTrait> as if it was SomeTrait

you can deref a box

yeah no problem

is it possible to mutably get stuff from the box

Have you tried using Box yet? (and then using the contents)

sunset: given Box<dyn Trait> you can call any of Trait's methods on the Box that don't have "where Self: Sized" attached

instead of a box can't I use a * or something?

I don't want to write closures that return boxes seems really not that clean to me

sunset: Honest question... have you read the Rust book?

err, can I not answer that?

Box is the cleanest option I think. Box is basically dynamically allocated memory, nothing fancy

ie, given x: Box<dyn JsSerializable> that yo umentioned in the bug, you can just do x.size() and x.ser(&mut cursor)

yes but the closure is not that fancy, and have to do Box::new at the return

it's what you use where you would in other languages use pointers, in my understanding

doesn't look cool

Please read it.

> doesn't look cool

Like, visually?

Or is there something deeper with Box you don't want in your program?

what is JsSerializable

but that means someone has to write | val| { ... return Box::new() } it's not aestetical at all

it's a trait snek

for what

you could return a reference &... but then you have to get your lifetimes right (i.e. the value must live long enough)

i'm curious about the project

snek: Probably something to do with Neon

to serialize a rust value to js, currently it works for primitive types, strings and some other types

sunset: use Box

i thought neon was unmainained

snek, why did you think that?

Last commit Jan 3rd

dunno

obviously i'm wrong

can I return & instead of a box?

sunset: If you don't want to use Rust because the syntax is visually unpleasant to you... I'm not sure what help we can give.

sunset: probably not

sunset: what I'd recommend in that case is something like fn register_callback<T:JsSerializable,F:Fn()-> T + 'static>(f: F) { actual_register_callback(move || Box::new(f()))

it's not that the syntax is unpleasant for me, I'd rather someone write a closure that does return 3; rather than box it

it doesn't look like clean code to me to force the user to box it

This is about ownership though

ie, you can make the function that registers the callback be generic over the return type, and then box it in there

You don't have to box it just for the hell of it, there is a reason.

eval: trait Trait {} fn foo(x: impl Fn() -> impl Trait) {}

talchas: I will think about that, but that would make like n versions for the function no? one for each impl I have?

I have quite a bit of them

sunset: in terms of compiled code, sure, but it would also likely be inlined

and would just result in the same code as if the user had written the Box::new

I see, thank you, I will look into doing that next time I work on it

So a gigantic amount of my build time with Cargo is spent outputting the progress bar because ConHost is slow on Windows

is there an alternative to using AtomicU64

rip

`time cargo build` with no changes takes around 2677ms on my project with lots of dependencies

building nightly kills my editor tooling

`time cargo build 2>/dev/null 1>/dev/null` is only 480ms

lpg: wow

maybe I'm messing something else up, but this isn't incredibly surprising to me

snek: outside of "use atomicusize and assert 64-bit" and "use Mutex<u64>", no

are either of those things worse

I suppose actually you could write asm wrappers and link to those

lol

you'll get worse optimization and have to do it on every 32-bit platform you care about but it would certainly work

screenshot from my terminal: i.imgur.com/saiuP2A.png

so if i want a static mutable u64

as a counter

i'm just sol unless i use nightly

yeah, I'm not going to defend atomicu64 still being unstable

lpg: just to be sure, you did modify the suorce between compiling?

no, that's with no changes

other than that it looks like it's finally going stable I think?

all of those runs were back-to-back

it'll be stable in 1.35

and just not defined on platforms without 64 bit atomic

s

but then the compiler won't really do anything IME?

oh sorry I misread. I thought you were timing the compilation

it spins for 2.2 SECONDS just showing a progress bar before it runs my program

cargo build 2>/dev/null && ./target/debug/foo is significantly faster than cargo run which is stupid

lpg: yeah, this sounds worthy of a bug report

alright, on it

lpg: though I believe cargo run -q will solve this for now

in terms of "gets rid of the progress bar"

talchas: that's a great trick, thanks

lpg: conhost?

or linux terminal?

git bash on cmd.exe on conhost

k

lpg: so yeah, conhost writes are super slow, and cargo's progress bar has to iterate through *every* crate

yup

with a lot of progress bar updates for each crate

lpg: Definitely file an issue

that's the hunch that I had, filing an issue now

I learned that working on a TUI tool called magic-school-bus and had to do soooo many stupid buffering tricks to make it fast on Windows

mmm

lpg: conhost has some interesting performance characteristics

like, if you write out a whole bunch in a single syscall, every time the color changes takes some time

so filling the screen in a single color in a single call? super quick

filling the screen with different color per cell in a single call? kinda slow

it's also very easy to get tearing with conhost; the terminal doesn't wait for the application to refresh

unless there's a mode I can set for that, which would be nice

you have to ensure your writes are done in a single buffered up call

lpg: technically, you can have two console frame buffers, write to the hidden one, and swap it out

what if I'm already in alternate buffer mode via VT100 emulation?

then you have to create another alternate buffer and swap between them :D

I've been keeping around a virtual screenbuffer and diffing it every step to minimize the actual console writes

it's wasteful on most non-conhost terminal emulators since clearing+redrawing everything is fast enough usually

I filed this issue, which probably isn't perfect: rust-lang/cargo #6661

golly, this affects cargo check too :(

lpg: could you do some kind of copy-on-write thing to capture changes as they're being made?

wpage: that might be kind of overkill since the total memory consumption to keep two terminal buffers around is very very small

the application I built using that has pretty distinct frames and is immediate mode-ish

diffing the whole frame is kind of expensive

depending on the size of the terminal window itself

can't be worst than what React does, right? :D

I don't know what react does - I've tried very hard to stay away from javascript development because of the framework-of-the-week situation there

React has been pretty stable for several years. You build a lightweight, ephemeral structure describing the shape of your UI and it's compared with the one from last time and used to incrementally update the DOM

lpg: but yea, I maximized my terminal window on a 2K display, and it's still only 8.27x as many cells as an 80x40 terminal, so diffing probably isn't that big a deal

I guess that is like 25 kB I have to diff for every screen update, which is not great

is there a way to safely index into a vec

i guess with a default would be ideal

vec.nth(0).unwrap_or(default)

vec.get(0).unwrap_or_default() iirc

yep

the "get" method takes an index and returns an option

ah get

though actually I think that you'd have to deref/copy, so it wouldn't actually work with just unwrap_or_default()

didn't see that in the options

guess i'm blind

if your type isn't copy, there's always Cow<'moo>!

its a vec of gc wrappers

so i have to clone anyway

is it considered an anti-pattern for a crate to pub use a crate that is part of its public API, so users can just use their re-export instead of adding it to their cargo.toml?

I'm writing some automation around rustup. Is there a good command which will give me the platform tuple for the current host? (e.g. `x86_64-unknown-linux-gnu`) I can currently grep and regex the output of `rustup show`, but is there a better command for just dumping the tuple directly?

I have a silly question. I have a struct with owned data. I want this struct to change type while just keeping the data, without extra memory allocation. How do I do that? Especially, if I do a.data = b.data; drop( b) will this copy?

mem::swap

ok cool thanks

Hey I posted this before - not sure if it made it to the channel as my network died. I'm looking for some info about the line where async becomes a good idea when using Tokio

async/await is certainly intended to replace futures/etc

najamelan: For owned types, `a.data = b.data` will move the data out of `b`

(replace common use of future combinators, that is)

it's more about how much you're willing to run into rough edges and bugs

for example if `data` is a String, this will not copy the contents of the string; it'll just make `a.data` point to the existing string data, and then mark `b.data` as uninitialized

starting with the fact that tokio is not built on 0.3 futures / async-await and you'll need to do compat stuff on all the boundaries

mbrubeck Are you saying it's cheap to just assign

and I shouldn't worry about it

even if types are Copy?

najamelan: Whether it's copy or move, the assignment will copy just the bits stored in that field, but won't do a "deep" copy of any data they point to

najamelan: A very large copy type, like a [u8; 1024] array, may be expensive to assign

talchas: tokio has an async/await preview feature flag

najamelan: But a type like Vec or String or HashMap is just a few bytes

and is cheap to move from one variable to another

eval: std::mem::size_of::<String>()

I actually dont know what a hashmap is

eval: std::mem::size_of::<HashMap>()

(what the size of a HashMap I meant)

ok, thanks I understand

but with mem::swap that would be completely free?

I mean is there a static way of changing the type around the data, without any runtime actions, just the compiler would now consider it a different type?

najamelan: mem::swap is just doing two assignments

i two structs have exactly the same memory layout, and I want to say to the compiler consider this to be Y instead of X from now on.

technically, the compiler isn't required to make them the same memory layout in many cases where you think it would (though in reality it's not going to at the moment and may well never)

and the way would be transmute or something equivalent

I would suggest constructing X

najamelan you probably will want to annotate both as repr(C) or something

najamelan: as mentioned, there is no guarantee that two structs w/ identical def have the same mem layout

I need to have a fixed type because I deserialize, so the type needs to be known, but then I want to send it of to different actix actors which subscribe to certain types of messages with actix-broker. To be able to filter the messages, they need to be of the right type

but actually they will all have the same fields with a vec<u8> payload

you could probably do this safely with just requiring a constructor, using a trait

I know I can just construct, and it will copy pointers to the heap, but it just feels wrong to copy when there is actually no need, even though this is a micro optimization

talchas, I don't exactly understand what you mean

I mean, fn foo(x: Foo) -> Bar { unsafe { transmute(x) } } and fn foo(x: Foo) -> Bar { Bar { stuff: x.stuff, other_stuff: x.other_stuff } } are identical

only the second one is guaranteed to work

I would the safe and correct thing first

it's only if you wanted Box<Foo> -> Box<Bar> or other pointer types where you would actually be saving any performance skipping an allocation

remember that any foo = bar; or foo(bar()) or foo = bar(); or anything like that is a copy already

yeah, I know

when it's passed to or from function it's on a different stack frame after all. Not much we can do about that