what are y'alls favorite talks on rust?

Hi guys, I've found something weird with lifetimes and things like f(expr). May be someone could answer me ? I explain:

buffer.resize(buffer.len() + foo, 0); doesn't compile, with buffer a mutable ref

zadig: the issue is that that's Vec::resize(&mut buffer, buffer.len() + foo, 0)

there is hope to fix this Soon(ish)

talchas, that's not normal, isn't it ?

zadig: That requires non-lexical lifetimes, which are not stable yet, check whether that compiles in nightly with #![feature(nll)] in the crate root.

nox, alright

in the meantime, use a temporary

thanks for your anwser :)

yup

zadig: I know this is covered in the NLL RFC, but I am not sure the unstable feature already implements that part of it.

(yet)

okay :)

not a big issue, but just not logical at the first view

zadig: For sure.

How does one re-export macros?

there is no way to do so on stable

So structopt's README is lying?

it requires #![feature(macro_reexport)] (old, soon deprecated way) or #![feature(use_extern_macros)] (new way)

I don't see anything about re-exporting macros in the readme?

No, but you also don't see a single `extern crate structopt_derive;` either

I guess like this then github.com/TeXitoi/structopt/blob/master/src/lib.rs#L342-L347

I vaguely remember seeing a debate about whether it's a bug that this works without #![feature(use_extern_macros)] :)

Maybe it's slightly different because it's a proc macro?

Just wildly guessing

is there a Some(v) | None for hashmap?

i see Entry, but no nice way to convert Entry => Option

lgspaw: are you looking for HashMap::get?

hm

this is different from `[]`?

neachdainn: yeah but proc macro scoping is supposedly unstable :p

lgspaw: right, indexing simply panics if the key doesn't exist

ohhhh ok ;)

thank you, this is exactly what im after

is there an Either type for results which aren't a Result?

need to get better at reading these doco, i shoulda just searched for "-> Option" on that page

!crate either

oh. right. I should really search crates first :( thanks!

`either` seems like one of those crates that should be in the standard library

it isn't quite as nice as I expected. Result is great because Err, Ok are semantically sensible whereas I don't care if it is Right or Left

For setting guid and uid on linux is an unsafe box with libc calls my best bet?

Like here: github.com/uutils/coreutils/blob/72…546b6e/src/chown/chown.rs#L266-L281

you might be interested in `nix` docs.rs/nix/0.10.0/nix/unistd/fn.chown.html

is there a function on Option that does (Some(2)).f(|x| Some(x+2)) to return Some(4)

(not map)

lgspaw: and_then'

ahhh

perfect

was looking for bind

yeah, bind is generally spelled and_then in rust

oh no, a haskeller :p

ok, good to know

(same with result and futures)

nope, coming from F# :)

soon you'll be asking how to do GeneralizeNewtypeDeriving and HKT

durka42: haskell spells bind >>= :P

(but yeah yeah, a haskeller would probably look for bind)

in F# its Option.bind for option coz no trait system

hrm nix lacks fchown, lchown, fchownat :(

can you specify rustc flags in cargo.toml? specifically "target-cpu=native"

usually you end up doing let (>>=) o f = Option.bind f o in the domain though

lgspaw: well, it's not a trait here either, just the whole inherent impl thing

hmm ok, so in this case its just a method?

(because you can't define Monad well without HKT, and the workarounds are ugly and probably have issues)

yeah

cjm: you can specify them in .cargo/config

fair enough

which is the second, secret, Cargo.tonml

cjm: github.com/mbrubeck/fast-rust/blob/master/src/022-rustflags.md

trait Monad { fn and_then<B>(self) -> Self<B>; } does not work

why is there no HKT if there is traits? it seems like it should be possible to encode them

er, well, missing the function, but whatever

that's the part that doesn't work

lgspaw: you can, that's the ugly workaround

right

durka42: the filename is just "config"?

"fn seq<F>(&self, fs: <Self as HKT<F>>::T) -> <Self as HKT<U>>::T where F: Fn(&<Self as HKT<F>>::C) -> U {" look at that type line

in a dir called .cargo, yes

ok, thanks

talchas: no I refuse :)

I think it says "fnord"?

interesting :) it isnt pretty but it works

and then I don't want to think about what a free function that's generic over M: Monad is supposed to look like

those type constraints on the impl are complicated (line 170)

i dont think im quite at that level in rust to grok that well

(you can't write the type equalities you might need at times, you can't write for<T> <M as HKT<T>>::U: Monad, etc)

hey, could anyone tell me how to get an X window using gtk-rs/cairo?

or in other words, using cairo with xcb backend

wait can i just use the xcb crate to get a connection?

talchas: well no... not generally... (>>=) is flat_map for iterators

mbrubeck: glad you like it =)

Is there a way to locate unused Cargo.toml entries easily?

jybs: you mean deps?

Yup

Put #[warn(unused_extern_crates)] at the main.rs/lib.rs, run compiler

centril: it's flat_map for Iterator and and_then for Option Result Future Stream (sorta)

Sweet!

And you need to match the extern crate statements in the source file and Cargo.toml to see if there's an obsolete

talchas: bit unfortunate that it isn't called `bind` or something more consistent

(I guess the best description of Stream is a stack, so that and_then is bind or lift bind)

talchas: lift bind?

are you referring to :: Applicative f => f (a -> b) -> (f a -> f b) ?

Is there any reason I shouldn't just wrap my entire program in a tokio::executor::current_thread::run(|_| { ?

Sudden haskal

Haskell*

centril: well, I forget what it would actually be

to apply bind to the correct place in a monad transformer stack

talchas: oh, lift :: (MonadTrans t, Monad m) => m a -> t m a

hmm so I set RUST_BACKTRACE=1 and my entire backtrace is: mingw_set_invalid_parameter_handler

yeah

what is that supposed to mean

and lift (>>=) isn't actually a thing, but "something vaguely like that"

talchas: maybe you are thinking of hackage.haskell.org/package/mmorph-…1.1.0/docs/Control-Monad-Morph.html ?

oh, I wasn't thinking of any particular actual function

besides that lift is vaguely the correct terminology

talchas: some day we might be able to encode such things and indexed monads in Rust =P

Challenge: what's the simplest way to write `fn flatten(Option<Option<T>>) -> Option<T>` in Rust?

`opt.and_then(|x| x)` is simple but I want to know if there's a simpler way

sleffy: fn flatten(opt: Option<Option<T>>) -> Option<T> { opt? }

centril, does that really work? I was under the impression that `?` must happen within a function returning `Result` at the moment?

sleffy: na, it works for Option now

I thoguht nightly relaxed that?

works on stable.

wow

holy crap!

AWESOME

:D :D :D

centril, that's still within a function block though

Is there a proposal for `Option::joint`?

sleffy: join* ?

centril, well rain on my parade, fine. I just like to get excited about everything I can :D

centril, join, yes

flatten

It's monadic join, after all `(>>= \x -> x)`

sleffy: you could propose it =P

too busy right now

Will the compiler optimize away slices created with slice::from_raw_parts if I just use it for "random" memory accesses?

I'm having some weird intermittent errors

That could indicate that

lachlansneff, I assume it might but only if it can optimize away the bounds checks.

What's going on?

lachlansneff: try it out with godbolt.org =)

normally optimizations aren't visible unless you're doing something that trips undefined behaviour

^^

or godbolt, of course :)

so I set RUST_BACKTRACE=1 and my entire backtrace is: mingw_set_invalid_parameter_handler

what is that supposed to mean

ngc0202: still no luck? :(

lol :)

not at all

ngc0202: can you swap to the native windows toolchain andsee if it gives a more sensible result?

yeah I guess I could try that

that's gnu or what?

MS Visual somethingosmething..

oh wait

that's what I thought I was using, but I only have it for stable not nightly

that explains some things

sleffy: I'm writing the vga buffer driver for a small "os"

Basically, it writes data to 0x8000

And that gets displayed on the screen

Sometimes, seemingly randomly, it doesn't display

lachlansneff: What architecture?

x86_64

lachlansneff: Also, you might want to use voltaile_write instead of a slice, otherwise the compiler is free to optimise out the write if it determines that it's never read

lachlansneff: ... why is the display at 0x8000 on x86_64?

mutabah: Will do

And whoops, I meant 0xb800

*0xb8000

if you're using qemu, and stopping your simulation with `cli; hlt` - watch out, last time I checked that will freeze the display without refreshing it (i.e. video writes just before the halt won't be reflected)

does anyone here by chance use both rental and owning_ref?

jpernst, I use owning_ref. Not rental though.

i'm considering increasing the scope of rental for the next version to include use cases covered by owning_ref, and am wondering if people would find that useful

possibly also with a macro that easily generates sound analogs of OwningHandle for any type

since it seems the OwningHandle scenario is fairly popular

mutabah: Now seems not to be working at all

Does this look right to you?

lachlansneff: what type is VGA_BUFFER?

mutabah: It's *mut 16

Whoops, sorry, `*mut u16`

Looks sane to me... assuming taht VGA_BUFFER is correctly set to b8000 and you're running in VGA text mode

Hmm

Seems to work when I comment some unrelated stuff out

If I'm about to start building a large and complex CLI with clap, what should I be using? The Rust representation, the YAML representation, or the macro representation?

can you add a method (impl) to a type outside its crate?

(e.g. type Test<'a> = HashMap<u32,something<'a>>; impl<'a> Test<'a> { ... }

)

lgspaw, I believe not.

lgspaw: I think "sortof". You can via new traits .. xion.io/post/code/rust-extension-traits.html

Yes, extension traits are one idiom to do this

Another is a newtype (`struct Test<'a>(HashMap<u32, something<'a>>);`)

is the other option to create a container type with a struct, then impl the struct?

And then implementing your methods on it

ahhh

And then implementing `Deref/DerefMut` on that struct to hackily get your methods back :)

yeah thats what i was thinking, didnt know you could make an anonymous struct like that though :)

lgspaw, yeah, they're called tuple structs! You can make 'em with as many tuple fields as you like

cool

how do you access the member?

ah i see there is a doc on tuple struct :)

ahh, you destructure it

or .0, .1 same as normal tuples

neat, i havent even come across tuples yet

Hi. Say I want to compile some Rust and compile some C and link them together.

With cyclical dependencies

Is it possible to do it with Cargo?

Or do I need to do the linking myself?

tremolo, you may want to use a build script

Is there a good idiom for doing a "struct object" similar to trait objects?

Lymia, what would a struct object be?

I have a non-object safe trait, which I can wrap a struct around -- the inherent methods of which would be object safe.

how do I just parse my own keyword in syn?

Lymia, ooh, interesting

I hit a very similar problem recently but did not find a solution. Would be curious to know if anyone else here knows

The best approach I can think of is to make a trait, then impl <T> Trait for WrapperType<T>

Possibly wrap it in a struct, with, like, struct Wrapper(...); impl Wrapper { fn new<T:NonObjectSafeTrait>(t: T): Wrapper }

Lymia, aye, but you've got to figure out how to erase the type inside `Wrapper` somehow

Where the contents of the Wrapper is a Box<WrapperInternalTrait>, which is trait WrapperInternalTrait { ... } struct WrapperInternal<T:WrappedTrait>(...); impl <T:WrappedTrait> WrapperInternalTrait for WrappedTrait<T>?

But that's not very DRY

Lots of shim methods :c

I guess a natural extension to the proposed "dyn Trait" syntax is

Something like "dyn SomeStruct<_>"

Though figuring out the semantics of that is hard

ngc0202: This syn example shows how to parse a custom syntax: github.com/dtolnay/syn/tree/master/examples/lazy-static

hmm could you point me to a line?

oh

well that's a custom parser from existing syntax

ngc0202: parsing a custom keyword would be similar to that link

the two parsers you would want are:

`ngc0202: syn!(Ident)`

followed by

`cond_reduce!(ngc0202 == "ngc0202")`

ahhh didn't think of that

thanks! great library btw

shoutout to geal too

woah, I just found parse_quote omg that cleans up some codeblocks so much

Rust code now part of supporting tooling at my job! :D

lpg: Oo that's cool! Can you tell us anything about it?

up to 4 lines of JS. :|

It was a little bit of greenfield tool development I did in my spare time, and it ended up being useful

Adopted because it was useful, and it just happened to be in Rust!

Nice!

It's also open source I guess!

hurray!

I need to make that happen at my workplace

so far I'm mostly just doing it with nix

I pitched rust at my job interview lol

and I got the job

so maybe someday I'll have rust at work :)

gotta graduate first

we're using a 30k LOC app in production

30k LOC rust?

i'm jealou

s

this project is only 1.5k LOC right now, lol

I'm at 1.1k loc for the gubment

but i think it's technically just a prototype and they're not going to use it

(well, 1.5k Rust, 1.6k Lua right now I guess)

i keep hitting brick walls when passing around hashsets to different functions, is there a more idiomatic way of doing this

(perhaps i should be looking to use impl instead of plain functions)

s/hashsets/hashmap

lgspaw: May you give an example of wall you've hit?

sure, i dont have really clear examples, but i was passing around HashMap (using insert in different functions) and i kept getting lifetime errors

it started to get unweidly and it seems mostly due to my lack of understandings of lifetimes

when i put everything in an impl, it seems most of those errors go away

lgspaw: If you could come up with an example of the playground, that would help. I am not sure what errors you got.

*on the playground

let me see if i can try

lgspaw: What is the type of your hashmap?

its a bit of a complex type, let me paste it

the main problem became passing the Cache around, i kept basically guessing what lifetime specifier, what mutability etc

Did you pass it as `&'b mut Cache<'a>`?

yeah

oh

no

i did &'a mut Cache<'a>

:(

This would cause the borrow of the cache to last too long

Because &'a mut T is invariant in T

im very unclear on this syntax, i should probably give this section of the book a read

This explains it: doc.rust-lang.org/nomicon/subtyping.html

excellent, i will read this

Hi what can one do with rust why is this new language

thugthggy: You can write software in Rust

Hello thugthggy, Rust is a general-purpose system-level language - You can write almost anything in it

almost?

write like what ?

games?

CLI apps, GUI apps, web servers, operating systems, games, compilers,

Video-games? Web apps ?

A web browser, a game, a terminal, an IRC client, whatever

web apps is tricky

In particular on the client side

well tbh with wasm

what is the difference between webapp and webserver ?

semantics

You can use wasm to do number crunching on the client side, but you still need JS to actually do any sort of IO with the user

wasm ??

on the server side you can of course use Rust all you want

but Rust in a browser is limited to what webassembly is able to do

any languge need JS on webbrowser correct ?

Webassembly depends on there being JS to call into the webassembly and do something with the results

and any language that compiles to webassembly therefore needs JS still

where there is no language alternative to js ?

There is no true alternative to JS at the moment

there are some languages that transpile to JS like coffeescript and so on

so, not too different from android and java a few years back

sad

javascript is the hardest language to me

typescript makes it better

what is typescript

it's javascript with types

transpiles down to javascript

i like type systems

Int :: Int -> Int like this ?? js with types means?

ok damn you rustfmt, can i stop rustfmt from putting newlines in struct instantiation? its turning a 500 line program to 900

been over configuration.md twice and i cant seem to find it

WindowsBunnyHasALongSuffixToday: queued, interesting. Thanks for sharing!

what's the most straightforward way to match on an Rc<String>?

CognitiveRadiation: deref to a &str and match on that?

CognitiveRadiation: you might also be interested to know that you can use Rc<str> instead with less indirection and overhead

Is there a parser crate that lets me get completions easily? I'm trying to implement a REPL; I can get everything that can be completed for a given CST node fairly easily, but actually going from index in the text to a CST node is hard

ha, this isn't for CLI options though -- I discovered structopt recently and I'm liking it just as much, since then I can reuse the doc-comments on my Options type as --help info

remexre: oh that is fancy

remexre: btw how goes the frunk stuff?

ahhhh

I'll do that _right_now_

remexre: awesome

remexre: btw... I moved Coprod into frunk_core

so the traits should be in frunk_core as well I think

ok

why does or_insert_with return a mutable reference, as opposed to just a reference?

(in hash_map, sorry)

(infact all the methods do)

Well, if you're inserting, a mutable refeence is the useful thing to return

Taking &mut and returning & is kinda useless

wrt why all the methods do, it's partially a hack around not having NLLs too

hmm thats true, i suppose entry() returns a &mut

lgspaw: it's to let things do `.or_insert(0) += 1` work

it wouldnt have occured to me to use such a thing

centril: For the name, AUnion (A = anonymous), ExtensibleCoProduct / ExtCoProduct, CoHList, or something else?

so, when you use .or_insert on the rhs of a match case, how do you balance this type if the contents of the HashMap are Option?

do you need to use &mut None?

or do you usually deref the result of or_insert

I have a function foo() -> Box<Future<Item=Bar, Error=Box<Error>>>. When I return a Box::new(ok(instance_of_andthen)) the compiler message seems incorrect to me: expected struct 'futures:AndThen', found struct 'Tile'. Shouldn't that be the other way around?

oh derefing seems to work well, hmm

Replace Tile with Bar :)

lgspaw: there's a nightly feature that improves the ergonomics of reference matching that'll make that a little better too

jon: What's ok() doing there? Why not just Box::new(and_then_thingy)

interesting

remexre: it's there because I'm still wrapping my head around futures :)

ha, fair

Is there a way to pass environment variables directly to cargo on invocation? For example, I'm cross-compiling, so openssl needs PKG_CONFIG_ALLOW_CROSS=1 set.

jon: So ok(T) -> Future<T, _>, so if you do ok(Future<T, E>), you get Future<Future<T, E>, E2>

So ok is used to turn something that's not a future into a future?

yup

The error message is backwards though, I _think_ that might be because it's doing unify(TraitObjectType, ReturnType) instead of unify(ReturnType, TailExprType), but I haven't actually done anything with rustc, so idk for sure

I found an issue about it, not sure if it's been fixed. rust-lang-nursery/futures-rs #402

I have a module with a number of enums that I use variants of frequently

so I have use self::Enum::*; at the top of all my functions here

is there a way I can make the scope of the `use` be greater than a single function, so I don't have to type all of htem?

Can tokio (not tokio_core) be used with hyper?

so, could you not just lift use statement outside the functions?

play.integer32.com/?gist=3e010359dd…0c2398308ae3aa86d4b9&version=stable how come function `test` fails to compile, but `test2` works fine?

lexical lifetimes. self is considered borrowed by get_a() until the end of the expression, that is the semicolon after get_b() call.

the NLL feature should solve that.

ahh

but meanwhile what you did in test2() is the sane workaround.

when is NLL coming?

no idea, tbh

fair enough

it is already there in nightly, but when it's gonna be stabilized

only the rust devs know

oh, im using nightlies, perhaps there is some feature i need to enable

#![feature(nll)]

awesome

Interestingly the error message actually implies that that self is already borrowed immutable by the outer method call before the compiler actually tries to calculate the function parameter. And not the other way around.

hoo boy feature(nll) gave me some interesting results :)

( rust-lang/rust #43234 )

awesome

> the error message actually implies that that self is already borrowed immutable by the outer method call <-- yeah, this might be closer to the truth. I'm not sure of the actual order of borrows inside expression, just that in this case there are two borrows in one.

s/closer to the truth/closer to compiler reasoning/

(the truth is of course in computing the inner expression first :>)

Can someone give me a hint why this [1] compiles on the playground without the "rc" feature flag [2] for serde?

[1] play.rust-lang.org/?gist=02bf9f46e7…a4183e11e19937a47967&version=stable

[2] github.com/integer32llc/rust-playgr…lob/master/compiler/base/Cargo.toml

1) I'm not exactly sure that the list of crates comes verbatim from integer32llc 2) some of the listed packages in there may require serde and enable feature "rc" themselves

as crates are compiled with the union of all features from all dependencies

and not just with features that are specified in your cargo.toml directly

Thanks! Didn't had in mind that all features are joined before the the crate is actually compiled.

how can i serialize a boxed trait ? it doesn't seem possible for serde

Did you include the `alloc` feature? (serde.rs/feature-flags.html)

can anyone speculate why a create with a native dependency may compile in one project, but fail in another? seems to be a linking issue

rnd-M: no I haven't seen that how can I try it?

boxed trait is a trait object. it doesn't seem possible for anything to serialize it. unless of course you add a serialize_to_json() method or somesuch in your trait.

which would internally call serde_json::serialize() or somesuch

tomtom: I assume you can't test the feature in the playground. Locally you just need to edit your Cargo.toml to sth. like: `serde = {version = "1.0.27", features = ["alloc"]}`. But as albel727 mentioned it may doesn't work at all but I would still give it a try.

rnd-M: i get #1[feature] may not be used on the stable release channel then

this is how one could remotely do it play.rust-lang.org/?gist=02a2b6b83d…1f04ddf4db53a112c5ad&version=stable

tomtom: Based on their documentation it seems like the `alloc` feature is nightly only. You need to run it with the nightly toolchain.

it certainly won't work because but trait objects, inside of Box or not, are unsized blobs of unknown and there's no safe way to get to their contents or figure out how to serialize them, unless you have a method to serialize them passed through their virtual table.

s/but//

now how could I even live without cats in labels.

albel727: =P

albel727: thanks, your solution seems to compile well :)

is there a way to test whether some item can be "imported"? I'd like to use SYS_mmap2 from the libc crate when it exists... except it only exists on a few platforms. Do I have to manually do cfg() juggling?

:(

that's where #ifdef is actually useful

yeah. well, you can always add a feature to your crate that would enable or disable use of sys_mmap2(), and so shove the responsibility onto your library users :>

presumably they will be able to test for current arch and enable the feature accordingly

you may invent your poor man contraption in build.rs that would behave like configure and enable features accordingly :>

albel727: haha a compilation test with use libc::SYS_mmap2?

yep :>

that's almost not a bad idea

but don't tell anyone I gave you ideas, or I'll be burned at stake

(and it's ugly still ._.)

I'll burn your name in the build.rs

nooooooooo

well, there are too many subtle things to consider. you'll have to properly pass things for cross-compilation, etc.

I wouldn't be brave enough to attempt this normally, unless I have absolutely no choice.

maybe I'd just use cc crate to compile a small C program with the #ifdef or call attempt, so that cc crate handles all this for me. ...and then hope that libc actually has the definition too. ._.

The compilation is not really a bad idea, I believe this is what ./configure scripts of yore did sometimes

>you may invent your poor man contraption in build.rs that would behave like *configure* :>

Ah :)

iow, exactly >_>

Build scripts are fun sometimes.

Reminds me that I should make a small helper crate for unhygienic code generation from build scripts :)

for sometimes ~ equal to 0.01% of the time :>

all the other time they're the horror <_<

(mostly so it keeps indentation levels correct)

Well so far my most elaborate build contraption is this: github.com/Xion/ezomyte/blob/master/build.rs

Featuring generatio of enums and Deserialize impls from a JSON spec

hmm, indentation levels... sounds like a work for rustfmt :>

Autoformatters are the devil so I don't use them :P

but but

no buts

but I need mine still :>

Not even generating Rust code through Python, so casul

well, as a first approximation, I wouldn't do compilation tests. I'd just check target arch in build.rs and enable feature when I deem it safe.

I have at least one project where I use Python to automatically copy the usage output from clap into README

Does that count? :)

hmm

nox: I'm going to generate rust code from C++, but I'm still pondering whether to do that in python or rust

glandium: IPDL stuff?

that sounds almost like markdown should be another "completion script" target or something.

nox: no, pure C++

for clap.

glandium: I mean, what's that Rust code you generate?

Ah, here it is: github.com/Xion/gisht/blob/master/tasks/build.py#L40 :)

nox: something awful, you don't want to know :)

I especially like the arbitrary cutting out empty lines

(and not empty ones, too)

glandium: I see you know me well.

What's the RFC for removing the generic types so you don't have to specifiy impl<T> Foo for Bar<T>?

This was covered in the impl period, right? Hope I am not mistaking something.

wat

That's moronic. Is it actually real? o_0

Xion_: Given your reaction, probably not. O.O

I mean, after it was deemed that `ref` is too much of a complication, I wouldn't be *too* surprised

Implicit > explicit seems to be Rust motto as of late

I remember one that propagated bounds from the type to the impl block

It's not done yet AFAIK.

That one I wouldn't mind, since I like having thematic impl blocks

aturon or woboats can confirm.

Though I'd prefer if it was something like `impl<_> Foo` rather than `impl Foo`.

So was there something along these lines or not?

I probably misremembered

Xion_: id :: a -> a ; id = \x -> x it is entirely reasonable to elide the forall. part

SuperFluffy, Xion_: IIRC the PR landed, but isn't implemented, and it's not sure it will become stable anyway.

Xion_: the way you're communicating makes me bummed out, fyi

but there's no RFC for `impl Foo === impl<T> Foo<T>` or something

centril: Which would be the equivalent of impl<> Foo for Bar<>

Not impl Foo for Bar which is ambiguous

woboats: They mean impl Foo<T> I think.

^

I think people are referring to "implied bounds" - if you have `struct Foo<T:Bar>` `impl<T> Foo<T>` works

nox: that's also not a thing

Xion_: you can certainly elide <> to nothing

woboats: nox indeed understood me right.

centril: And then it's not clear if the trait itself is parametrized

woboats: I was thinking of impl<T> Foo<T> = impl Foo<T>

Xion_: you are arguing readability, I'm arguing what is technically possible

SuperFluffy: the concern with that has to do with shadowing

Ah it never made it to the RFC I see.

centril: Not everything that's technically possible should be done :)

SuperFluffy: that is not doable... T can be a concrete type

what if you have a glob import that adds a type called `T`

now its no longer a generic type

centril: something something preoccupied scientists ;)

SuperFluffy: Some Erlang people name their state record 'ate',

unlikely for `T` of course, but if you did something like `impl Foo<Ptr>`

woboats: Yeah, indeed. I was just thinking about that.

so they can name the variable St and do St#ate.

Well, let's ban single-character types and reserver A, B, ..., T for generics? :D

SuperFluffy: Or just don't omit them and make the next person who will read the code happy.

^

woboats: tho if we roll back history and say that initial caps-idents are for concrete types and initiaö-lowercase is for type variables then it works fine like in Haskell, but we can't roll back time

s/initiaö/initial

nox: Reminds me of the attr library in Python

(which has API like attr.s and attr.ib)

(quite del.icio.us, I'd say)

centril: Have you worked with idris?

Xion_: I'm ok with implied `ref`, I'm not ok with implied `mut`.

Xion_: Implied `ref` at worst can cause a compile error because you tried to consume the binding later but it was actually a reference,

SuperFluffy: No; I've only read about Idris - I've used Haskell extensively and Agda a bit tho

implied `mut` means I can mutate the damn value in the middle of nowhere without any sort of visual cue.

I like what I've seen so far

pastebin.mozilla.org/9078384 such consistency across libcs... when what supports those syscalls is the kernel

Tbf, the fact that Rust requires `mut` for local variable mutation can be seen as weird in itself

centril: After reading tdd with idris, I was confused that I couldn't return types in rust. :D

>`mut` for local variable mutation can be seen as weird in itself <-- let it be seen as such, idgaf

And who knows, maybe the lack of `ref` will bring some consistency as to what and when is deref, or de-derefed, automatically

glandium: There is a crate for mmap.

albel727: Blasphemous infidels, those who think that, yes ;p

:D

Xion_: I disagree about it being weird.

SuperFluffy: you can - use associated types as type families

nox: it uses libc

Xion_: If I init a value immutably, I want it to be the same 30 lines later, barring internal mutability.

immutable by default vars. best thing for reasoning since coffee

glandium: Oh, that's your custom allocator?

albel727: People want `mut` to be implied on owned values.

let them use another language then

And have cake.

nox: yes, and I do need to use syscall() because of stupid LD_PRELOADs wrapping mmap

>but but muh implicit things saves on typing <-- should direct efforts towards a sane ide then.

albel727: Some people argued that your IDE can tell you a variable is actually mutated.

When Niko has expressed that `mut` on owned values might be silly boilerplate, maybe you shouldn't be so sarcastic about that opinion

nox: an IDE shouldn't be mandatory to review code

^

woboats: Could you not call that property that I value 'silly'? Thank you very much.

glandium: I 100% agree.

Personally, I like the 'mut' keyword; feels like a good hint where it matters

Just because I own a value doesn't mean I should be able to mutate it.

^

is there a way to tell cargo to use something else than link.exe when linking for an msvc target

?

But let's respect disagreements shall we and discuss only based on merits?

centril: Sure.

i think the important point is that `&/&mut` is a much more meaningful distinction than mut or not on a local variable

from the point of view of correctness of the rest of your program, you *can* mutate anything oyu own

No.

From the POV of safety, sure.

Not correctness.

Correctness implies the absence of logic errors.

Mutating something that I don't expect to mutate is a logic error.

this is why i said correctness of the rest of your program

I don't see why "the rest" changes something here.

The explicit `mut` marker prevents that I don't mutate things by inadvertance, even things I own.

because the rest of your program can't observe the state of your local variables

I agree with woboats here; Maybe there should be some way to say that you are not permitted to mutate an owned value, not even by moving..?

My years of doing PHP showed me that mutating things that I own can be a logic error.

why "the rest of the program" is to be the ultimate judge of what is useful, again?

CARGO_TARGET_X86_64_PC_WINDOWS_MSVC_LINKER was the answer to my question, in case someone else was wondering

My years of doing Erlang showed me that immutable by default is a very nice way to avoid that whole class of errors.

but its a *local* logic error is the distinction nox

woboats: Again, I don't see why that matters.

whereas `&/&mut` is important for nonlocal correctness

Why should we kill sometimes that matter for local correctness?

nox: no one is suggesting "killing" anything

woboats: what about wanting to disallow mutation globally so that you can freeze an owned value at some point..?

We are suggesting to make `mut` implied.

there's no proposal from removing `mut`

There is no RFC, but there are discussions.

there is no momentum behind that idea

Good.

when I referenced niko's comments, the real point was there are cases where you might actually really *want* to see that mutability, but can't

whereas you are *required* to see it for mutating local values

where it is less useful, because it is *only* local reasoning

woboats: what comments are we discussing? got a link per any chance?

i feel like theyve only been made in person, sorry

but consider a function that returns an &mut T

or that takes an Fn(&mut T)

you can use this API without ever using the `mut` keyword

centril: SimonSapin started a thread I think. But I may be misremembering.

this mutation involves the interaction between multiple parts of your program, but its "implicit"

interesting =)

I don't see how the fact that there is sometimes no `&mut` written anywhere is bad means that maybe the required `mut` should be omitted.

nox: its not that its bad, its that we put our attention where it was less important

because we are still learning the nuances of the language that we have already built

That still doesn't make `mut` "silly" in my book.

Maybe that idea is a bad one... or interesting..? idk

>freeze <-- iow make mut the default, and constness requiring the keyword. thanks but no thanks :>

albel727: that's not what centril is proposing

oic

forever immutable owned value

albel727: yes exactly

perhaps it is not that useful..?

centril: it seems a lot like what the Pin type I've been working on for generators does

well most cases I see could be covered with a wrapper struct with Deref

specifically in its stack pinned variant

I wonder if `let freeze` would guarantee Drop.

woboats: I also had some vague notion that it could be related =)

can't

nox, centril: I have argued informally that `mut` in patterns (like `let mut foo = …;`, not in `&mut _` types) is useless and I’d like to see it made unnecessary to mutate bindings. I have not written any thread or RFC.

you let freeze, then the kernel decides you never run again, Drop is now not run

SimonSapin: ACK

`let freeze` is arguably even more silly since nobody would bother to write it

just like `const` in C++

OmniMancer: That's different, I don't mind if the program aborts.

nox: SYN

or if they do, only sporadically

Anyway, lunch time.

nox: similar for the kernel decides to never schedule that thread ever again but let the rest of the threads run peacfully

nox, centril: I also *call* `&mut _` and `&_` exclusive/shared references rather than mutable/immutable, but I think it’s probably too late to rename `&mut _` in the language syntax

by about 3 years, SimonSapin ;)

SimonSapin: If &mut was &exclusive,

I would be arguing for a mechanism to prevent mutation without visual clues.

cues*

SimonSapin: I think that is right morally, so we can talk about them in exclusive/shared terms

^

:>

woboats: I mean we could maybe add a synonym and deprecate the old one at an epoch boundary, but it’s probably not worth the disruption

stupid irc, why doesn't it have happens-before :>

albel727: clearly we need fearless IRC ^,-

:D

SimonSapin: why do you feel that let mut foo = .. ; is useless?

(the mut bit..)

centril: the compiler always know wether it’s necessary or not

centril: The reality of it is that we wouldn't be having this discussion if Servo didn't take 15 minutes to build.

>languages are for compilers :>

centril: I regularly make a change or write new code, compile it, and then have to go back to add or remove some mut keywords

SimonSapin: well that is true in a lot of cases but we still don't elide... the question should be if removing the need for 'mut' improves readability or not

it’s busy work

SimonSapin: well technically the compiler always knows whether it is required to compile, it doesn't know whether your mutation is incorrect to do

albel727: there's no need to make reductive strawmen of other peoples' positions

no, on the contrary, I quite find it necessary in this case.

How is it a strawman to point out that languages aren't for compilers?

because no one claimed that they were

For me personally that compiler error ways "I need to add `mut` somewhere" every single time. I haven’t seen a case where it caught actually-unintended mutation

No one claimed that anyone claimed that.

s/ways/is always/

SimonSapin: I sympathise but I feel that the core problem lies with compiler performance here... if we improve things and have a neat REPL then that might be less of an issue?

I have the same experience as SimonSapin, but I almost always remember to add `mut` so I don't mind it

one case that's actually confusing is when you declare a variable, don't mutate it but pass mutable ownership to a function

Yaniel: That needs `mut`.

and the compiler says you don't need to declare it as mutable

Yaniel: No.

If you take &mut foo, you need `foo` to be mutable already.

nox: it does not, moving a thing never requires mut

nox: Yaniel said ownership

What's mutable ownership then?

having performant compiler and sane IDEs would preclude having so many arguments. like >let's pull the python 2/3 split stunt on the module system because use statements were mutilated, because :: prefix was considered too heavy to type (even though it's a great entry point for completion in any IDE, not to mention that use statements can be added automatically), and we don't want to fix "use"

the thing is that there's no such thing as "mutable ownership"

&mut requires it

Ah, ok.

but moving it into the function and the function mutating it is not needing mut

the fact that you put `mut` on the function argument makes it seem like its a different kind of ownership

woboats: yeah, I misread what Yaniel said too

especially since there's the connection to `&` and `&mut`

OmniMancer: You gave up ownership of it,

why would it need to be mutable?

nox: indeed

centril: even with better compiler performance it’s still busy work IMO

OmniMancer: Oops sorry confused you with Yaniel who made the original point in this discussion.

when you can do `let vec = vec![]; let vec = foo(vec);`, but `foo` mutates it, the notion of "immutability" seems a bit stretched

SimonSapin: sure; some busy work may be acceptable tho for improved readability - there's the trade off btw writing and reading and I tend to favour reading

woboats: I don't see how.

If I sell you my phone, why would I care that you mod it afterwards?

because of shadowing, you can't actually assume that because you see an immutable `let` binding, that name refers to the same thing every time you see it

Yes I can assume that.

well what specifically do you see as the benefit of knowing a variable is immutable, nox?

right, and then we get into subjective judgment of how much is readablity improved by this

you *can't*, unless you've confirmed its not shadowed between that binding and this location

woboats: That I can't mutate it.

If I see a variable used, I can go upwards to find where it was defined,

(1 click in an IDE)

and if there is no mut I can be sure it wasn't mutated, barring interior mutability.

albel727: Yeah, that too.

unless you've missed a `let` binding

Why would I?

SimonSapin: can't argue with that... eventually things get subjective, but I think that doing nothing should be our default position and doing something has the burden of proof

If I focus a word in my editor it highlights every single occurrence of it.

in the general case

nox: your IDE could also highlight every mutation

With way more tooling.

SimonSapin: bon apetit

And that means I need the IDE to review the code.

Or to comprehend it.

Then I can't do anything on my phone.

It isn't my experience that I can't comprehend code without the `mut` keyword

It is my experience that implicit mutation caused issues for me without explicit visual cues.

but as I said, I never get errors about needing to add the keyword either, so I don't mind it existing for people with a different experience

woboats: I agree; but 'mut' let's you see easier when mutation is going on imo

s/easier/quicker

In contrast, its my experience that *aliased mutation* causes hard to solve bugs & technnical debt, so I think its very important and great that Rust solves that problem

Exactly, just because shadowing can make you miss some doesn't mean you should just allow all mutations all the time on owned things.

^

I'd like to know if we all felt the same way about "implicit mutation" if we had access to a language where mutation was implicit, but never aliased

I have access to a language where there is no mutation, and I had way less errors due to implicit mutations (heh) than I had in PHP with it. And I was more confident about my own reviews in it.

woboats: Personally I always prefer functional programming and not mutation (acceptable as optimization), so I wouldn't be in favor of it personally

albel727++

not to mention that having a variable binding immutable sort of puts an upper bound on complexity of control flow around it.

albel727: could you elaborate? i dont know what you mean

things that don't change can't cause confusing loop termination conditions

^

e.g

I was typing my examples, so thanks for saving me the effort and putting up a concise example

But they can be changed through shadowing

not in a loop in rust

I suppose the thing is that doesn't impact things like `while` headers

anything you can shadow in the loop stays in that loop only

when you have a variable and a loop, it's immediately more liberating to see that it's immutable, because you know that however weird things are going in the loop, they don't accumulate chaos through the external binding.

but you could easily do `let x = 0; loop { let x = rand(); if x != 0 { break; } }`

sure

now do it accidentally

I think the key point is >accumulate chaos

you can do chaos in the loop, but it never becomes so unpredictable as you have to reason about N+ iterations of the loop.

The notion of accumulated chaos is interesting

Yeah

Well you have to reason about it for every mutable variable outside the loop, but not for the immutable variables

so now you have to either remember which ones you have to care about or which ones you don't have to care about

yeah. which is why dwindling mutable variable numbers is a good thing. and immutable-by-default bindings is the only thing that lets to do that in practice.

it makes sense as a way to mitigate complexity

it makes a whole world of sense, especially when reading code, kindly believe me on that.

I feel like most things that improve readability at some point could be considered "unnecessary"

yeah, when AI comes by :>

doesn't make Perl code any easier to reason about

OmniMancer: Yeah that makes me sad.

you don't need to reason about it. you just tell AI to do things, and it does. until one day it hates you so much for having to read perl code, that it ends humanity. the end. :>

Oh also a bunch of features I see evaluated for how they affect existing code or writing code

but not for how they affect you changing code that already exists that you may not fully understand

OmniMancer: that is actually a huge influence on our decision making

woboats: I imagine it is, but it does not always seem to be considered this way when RFCs are discussed

but that is just the feeling I get sometimes from reading some comments and I have not looked at RFC discussion in ages

its hard to develop a shared language we can use to talk about that kind of situation

woboats: neat emoji on I-unsound =P

centril: dont add any more

centril: unfortunately it changes the URL

woboats: o.O how unfortunate

hoping no one is tracking the I-unsound tag in any documents, but it might have to get changed back

definitely there are other tags it would be very disruptive to add emoji to

woboats: too bad you can't have emoji + separate slug

separate url-slug*

yea :-\

woboats: maybe emoji in description?

figured adding a joke to I-unsound would be lighthearted w/o going overboard

woboats: It was a nice one!

it also emphasizes that I-unsound is sort of the worst kind of bug

woboats: Yeah, I wanted to communicate that but really couldn't find the right words

but an image says more than...

woboats: I put dragon emojis in my commits that require extensive unsafe review.

Join the dragon train too!

Look... some ❄️ (ICE)

Where is Yuri?

meh... what a gigantic bummer, I can't use 🐢 (turtle) for I-slow

play.integer32.com/?gist=3310dda3b5…9d1bfd762558e5ded49&version=nightly im struggling with this error, ive got a feeling i need to have two lifetimes

oli_obk_: Is there are reason for why the features field (and a few others) in cargo_metadata::Dependency is private?

( github.com/oli-obk/cargo_metadata/b…23646f5037924/src/dependency.rs#L51 )

centril: Why not?

panicbit: not really... noone needed them and it's backwards compatible to make them public

Cool

I'll make them public then :)

ok

nox: above 0x... something something =)

1

SimonSapin: > but I think it’s probably too late to rename `&mut _` in the language syntax

we have epochs now

& and &exc might be better

or &ex

or similar

gnzlbg: that seems very counterintuitive... I have no clue what `exc` would mean

mut in patterns and mut in references are just two different things

oli_obk_: I am bad at naming

but arguably it is better to not know what something means and look it up

than to be wrong about what it means

It's not wrong to consider &mut to be about mutation though.

centril: Wait what, GH doesn't even handle Unicode correctly?

I am still a bit worried about epochs :/

well, one can see how &mut and &exc can be not exactly the same. current &mut T is like &exc mut T, and the question is if "&exc T" to mean "a borrow that is guaranteed to be exclusive, but without ability to mutate" is a useful thing to want to express. if not, then conflating "&exc mut" to just &mut like it is now doesn't seem to be wrong.

nox: mutation follows from exclusive access, not the other way around

gnzlbg: That doesn't change what I said.

OmniMancer: If they don't turn out to be good we can just release a new epoch without epochs ¯\_(ツ)_/¯

nox: & has nothing to do with mutation though

And?

&mut => mutation would imply that & => no mutation

which is wrong

& => immutable &mut => mutable is still a very good simplification.

it doesn't have nothing to do with mutation

OmniMancer: Yep.

it just has a complicated relationship with mutation

Don't we all have

&mut guarantees it is mutable

& might be mutable depending on the type

nox: like all imperfect simplifications, it works till it breaks

wait, "& => no mutation" seems to me pretty correct here. interior mutability is just a hack from the impure real world.

So what's your point?

albel727: Some people argue that `mut` is useless because "what about interior mutability".

._.

and no aliasing

(amongst other things)

Aliasing doesn't matter for logic errors.

I don't think even with epochs it is worth changing

if you want __restrict you use &mut

OmniMancer++

independently of whether you want mutaiton or not

making all documentation and resources about rust wrong again after 1.0 would be very bad

nox: I wasn't arguing that mut is usless, I was arguing that mut is not the best name

and that now we have epochs for syntactic changes

gnzlbg: But if mut wasn't named mut, I would be arguing for an additional thing named mut to explicitly state one wants mutation.

When I started out, Cell and RefCell really confused me. I always wondered, if this was a concept unique to Rust, or do other languages have this, too?

nox: let mut x would still be a thing

he would be arguing for &exc mut thing

gnzlbg: Why would `let mut` allow one to call `&exclusive self` methods, then?

then i would be arguing that mut there is not necessary

gnzlbg: so then the question would be why can't I take &exc of a thing that isn't declared mut

nox: sure

OmniMancer: Oh yeah, you phrased that better.

gnzlbg: most things are not necessary

wait, you won't be arguing against "let mut", but would be arguing against "&exc mut T"? how is that consistent?

OmniMancer: gotchat

for some definition of necessary

i see the motivation for &exc mut

and &exc

I think `let mut` allowing one to call `&mut_not_named_mut self` would be even more confusing that the current state.

idk, maybe

rust currently doesn't allow no aliasing + no mutation

I still think that even with epochs they should not be an excuse to tinker with things that already exist and work fine but some people don't like the nomenclature

OmniMancer: I have a lot of code that uses &mut for: no aliasing + no mutation

changing the syntax for things that already exist has non trivial costs

because &mut is the only way to get no aliasing

"a lot", more like, "some code"

do you have an example? I was kind of were aiming for those, when I posed a "if &exc mut T is a useful thing to want to express" question before.

I use it in kernels to express __restrict

s/were//

even if I am only reading from a variable

I see epochs as a useful tool for adding syntax that is technically a breaking change, not as an excuse to rewrite the whole syntax of the existing language arbitrarily

well, maybe introduce a third kind of borrow, &exc, then. making everyone write "&exc mut" to mean "&mut" would be penalizing the most common case.

OmniMancer: Mostly agreed. Though introducing dyn and eventually deprecating dyn-less trait objects is useful IMO, so not a hard rule

albel727, nox, woboats, et al. ^

ajeffrey: ^

rkruppe: there may be exceptions yea, not sure how I feel about the dyn thing

centril: What a communist idea. If you own something, you should be able to do whatever you want with it ;p

Actually writing this down made me think about the rules involved =P

Xion_: so you are saying steveklabnik and I would approve =P

but in general a way to make breaking syntax changes is not license to break all the syntax constantly without having a very very good reason

centril: Salut camarade.

centril: What's the motivation?

rkruppe: nothing specific right now, it was a #rust provoked idea

see discussion above and backlog

centril: I'm having fun with types today.

centril: play.rust-lang.org/?gist=2b4d13092c…425564084a09f06779a4&version=stable

nox: Debout, les damnés de la terre; Debout, les forçats de la faim...

=P

so how would we introduce an exclusive non-mut borrow?

centril: My gut feeling is that this is a lot of machinery and a lot of limitations for something that has no good use at all

&mut non_mut foo ?

centril: ✊

or &mut_non_mut foo

nox: weechat didn't render that correctly :(

centril: Fix your client. :p

maybe &mut_immutable

rkruppe: hi

rkruppe: hence: "These are just some vague ideas at this point and may be wholly useless or very not nice to work with" =P

centril: U+270A RAISED FIST

gnzlbg: hi

nox: ah, cool =P

>a frozen T is a subtype of T <-- wait, how is that correct. you can't pass a value of frozen T to anything that takes T.

I started trying to figure out how to do the multiple source compilation in rustc

albel727: oh yes, that is not correct

*single source, multiple targets

centril: Sure

albel727: the reverse is tho - T <: frozen T

yeah

albel727: fixed, thanks

gnzlbg: &&mut T :P

V:

(well, that one is clever, but unfortunately still effectively the same as &T, wrt aliasing)

albel727: the inner reference is unaliased

oh wait no

yea not useful :P

well except that it guarantees the inner referrent had no & refs at the time the &mut was made

yeah, it has no & refs for the duration of inner &mut lifetime... but now has a bunch of &&mut refs :>

nox: type hackery is always fun

does &mut&&mut T work though?

so you have a &mut to *one of* the &&mut T refs. fascinating :>

now you can show that ref, who's the boss here <:

I guess if you have an operation that takes the &mut T and manufactures the &mut&&mut T directly it will be unaliased, but otherwise not

centril: I HEARD YOU LIKE TRAIT BOUNDS play.rust-lang.org/?gist=1da4c1ae65…c611188bc365451197aa&version=stable

yeah, as a matter of raw fact. but the point is also to make that information available to the compiler at all places of use, so that it can make optimizations. and if you write your function signature like fn blah(arg1: &mut&&mut T, arg2: <same>), it in general can't deduce that arg1 != arg2

albel727: In some part of Servo, I'm currently passing a glorified &mut &'a UnsafeCell<T>.

nox: beautiful, but Sean Griffin likes em more

albel727: huh? arg1 and arg2 absolutely must be distinct. (the innermost &mut can be aliased, ofc, since it's behind a &)

nox: nice use of the Length<Kind>: Storage thingy

centril: So I tried to be a mechanical turk when I wrote the TCV impl for Length<Kind>,

rkruppe: yeah, it was roughly speaking. of couse I was meaning the innermost one.

*course

centril: and I forgot ` Length<<Kind as ToComputedValue>::Output>: Storage`,

but I think this one can also be D E D U C E D automatically by the deriving code.

nox: methinks that is right

centril: The back story is that Stylo has insane amounts of generics,

centril: just because many things have different representations whether they are specified or computed values.

We currently have one type param per thing which representation vary depending on the kind of values in the structure,

trying to make that a single type param marker.

nox: btw, you can do type Foo<K> = <K as ToComputedValue>::Output;

which is pretty neat

centril: Yeah I know, but this is supposed to be behind a derive anyway. :)

=)

centril: I guess that may make the docs look better though…

nox: yeah

centril: doc.servo.org/geckolib/style/values….Gradient.html#impl-ToComputedValue

If I can make that Gradient<Specified> -> Gradient<Computed>, I'll be pretty hyped.

nox: oh holy mother of...

centril: Heh. :D

nox: Generics for the Generic god, constraints for the constraint throne?

centril: #[derive(Animate, Clone, ComputeSquaredDistance, Copy, Debug, MallocSizeOf, Parse, PartialEq, ToAnimatedValue, ToAnimatedZero, ToComputedValue, ToCss)]

nox: I'm assuming you guys are pretty stoked about impl Trait

centril: Not even, this is all derived so we don't care.

but still... makes docs more readable

centril: Well where would they here, though?

We store all kinds of values, specified, computed and animated, so we need them types to be concrete.

>inb4 naming types by return type of a function name

nox: oh it doesn't apply here I think... but type CV<TCV> = <TCV as ToComputedValue>::ComputedValue; would help a lot in this particular link

centril: Yeah I agree.

would reduce reading complexity to half I think

Nice #[derive]

Maybe there should be a convention that in derives like this, you should order the traits like you'd order imports: standard ones first, then third-party ones, then own project's ones.

there usually aren't that many, that lexicographical order doesn't work.

albel727: +1

n.b. "like this"

centril: play.rust-lang.org/?gist=fdcc505201…a054dcd538588dde9&version=undefined

heya

locals, conditions, loops... anything else on the const eval wishlist?

nox: "Kind" is giving me HKT vibes =P

centril: The names are bad.

centril: Not sure which one I prefer between the two.

(The two playgrounds, not talking about naming.)

The latter is simpler,

but Length<Computed> looks better than Value<SpecifiedLength, Computed>.

nox: idk, I can't put it in the proper context to judge =)

Hi, what should I use for a filesystem-backed set of hashes? (literally a set of md5 hashes). I need quick "add" and "contains" operations. Is there anything more lightweight for this than a full database?

Mateon1: md5 hashes are very small, are you sure you need to to be backed by the file system?

centril: Basically trying to bring order to github.com/servo/servo/tree/master/components/style/values :p

rkruppe: I definitely need it to be saved to persistent storage, I'm not sure if serializing it on program exit is good enough. I expect to store a few million hashes at a time

Mateon1: Is that for Servo fuzzing, my hero?

=)

Mateon1: Serializing on exit and deserializing at startup seems much simpler than maintaining a file during operation (and likely easier to make fast too, unless you do only a few operations per run). A few million hashes is dirt cheap -- in the order of MBs

nox: Yes, I'm running into problems with constantly repeating reductions I've already tried. I could improve effective performance possibly 10x

is there currently any way to pass two different Fn-trait implementing functions to .filter() ?

apparently, Box<Fn> does not implement Fn yet?

Huh?

sgflt: &Fn implements Fn though

rkruppe: ah, thanks

rkruppe: Yeah, I see. That's probably fine for a few million, that fits in 100 MBs even. A BTreeSet will probably be fine

rkruppe: still can't pass that to .filter though, i think

sgflt: Why not?

sgflt: You can pass &your_boxed_closure.

how am i supposed to read that: : std::ops::Fn<((std::string::String, std::string::String),)>` is not satisfied

the extra , in there is driving me a bit crazy

sgflt: Show us the code you wrote.

nox: i'll put it up on the playground, 1 sec

Seems like you wrote Fn<(String, String)> instead of Fn(String, String) or something like that.

Err no, maybe the opposite rather.

You tried to call a binary function with a pair instead of two arguments

nox: play.rust-lang.org/?gist=cc41f51cc3…1fe79f1e24d13395872a&version=stable

whoups, that is supposed to be filter_map

sgflt: s/FnMut/Fn/ for starters.

sgflt: You either make a Box<Fn> and borrow that immutably,

or you make a Box<FnMut> and borrow that mutably,

but an immutable Box<FnMut> is useless.

right

that does not seem to affect the issue with the missing trait implementation though, if i am not messing this up elsewhere

It does.

sgflt: play.rust-lang.org/?gist=10e3ad5054…90e0a8ace0971a669dce&version=stable

and play.rust-lang.org/?gist=03f7f41f73…5d14cff9d700fc284e0c&version=stable

so the &* cast was missing?

sgflt: Yeah. Either &* with Fn or &mut * with FnMut.

nox: thanks

is it kosher in a build script (for a -sys crate) to download a tarball to build from source?

cmyr: that would make me sad, since it prevents me from rebuilding when working offline

cmyr: why don't you just add the source you need as a submodule?

then it'll be in the crates.io project

oli_obk_: the source I'm looking at (for gdbm) is harder to build from the cvs source than from the tarball

the tarball already has the ./configure script set up

oli_obk_: const effect polymorphism thank you =)

cmyr: No.

but that mostly depends on me fixing up my RFC one day

centril: wat is that?

A build script ain't supposed to download stuff.

oli_obk_: some modified version of: rust-lang/rfcs #2237

cmyr: Just vendor the code in your own crate.

hmm, but what about a buildscript (like for libgit2-sys) having an external submodule?

yea alright

centril: In my second playground, I guess I can do type Length<Kind> = Value<SpecifiedLength, Kind>.

nox: that is nice =)

oli_obk_: "for loops are technically allowed, too, but can't be used in practice because each iteration calls iterator.next(), which is not a const fn and thus can't be called within constants" <-- how sad; my RFC aims to fix that.

centril: ah :)

cool

I'll have a look

centril: miri-wise this won't be a problem

oli_obk_: I haven't updated it in months, so be sure to read the discussion, especially eternaleye's comments for the current thinking

oli_obk_: =)

centril: play.rust-lang.org/?gist=9f01b6268f…110996a346bad17e2959&version=stable :O

centril: Don't actually need Value<T, Kind>, PogChamp.

centril: What do you think of s/Kind/Family/?

trying to 'impl<'a> From<&'a [f64]>', and then Im calling &vec.into(), but that doesn't seem to work. 'the trait `std::convert::From<&std::vec::Vec<f64>>` is not implemented'

j_ey: (*vec).into()

ah

j_ey: Or use From.

From::from(vec) ?

j_ey: Nah, with the explicit result type instead of From,

I dont quite get why *vec works

to nudge type inference a bit.

j_ey: Because the type checker had not enough info for the inferenec.

'inferenec' looks cool, but I meant inference.

sorry, not quite sure what you mean with 'with the explicit result type instead of From'

j_ey: Vec::from(&vec) if you wanted to build a Vec<T>.

ahh

Stats::from(&*times) this works too

nox: Kind seems better - but I think you will end up with a generic name

and that is fine

centril: I thought "type family",

centril: but not sure which one is the biggest misuse between Kind and Family. :D

nox: I think the misuse is on the Haskell side calling types of types "kind"

Agda does this better and less confusingly

but then Agda is also consistent as a logic and you don't have * :: * so it has to be less jumbled and confusing

oli_obk_: left you a bunch of review comments on your loop rfc =)

centril: You just reminded me Hewitt's "maths are self-consistent", pls no

one of my favorite things about the Rust community is that I'm not alone in having suffered through Hewitt

I'm only half joking

nox: Curry-Howard is beautiful

centril: thx, I'll address whatever I didn't comment on ;)

It let's programmers claim they are mathematicians

rkruppe: Ah ah.

oli_obk_: I think I got rickrolled by a stack-overflow question on #[recursion_limit = "<limit>"] =P

oli_obk_: uhm... github.com/rust-lang/rust/blob/f76d…/librustc/middle/recursion_limit.rs

or master: github.com/rust-lang/rust/blob/mast…/librustc/middle/recursion_limit.rs

centril: Do you know of code similar to the playground I linked with the Kind stuff btw?

There's `move || {}`, but how can I clone a value into a closure, instead of moving?

some nice syntax for that too?

No special syntax, create a clone manually outside the closure and use that in the closure

okay

was about to do that, but couldn't hurt to ask

Oh my god this is frustrating. I can't think of a way to pass a clone of a certain struct to hyper, cause .bind() takes a Fn() -> T, and any outside cell "may outlive" main

I also tried extremely unsafe raw pointer manipulation, but I failed at it

oli_obk_: nice changes in the motivation

I think I need a Cell that is Copy

nox: perhaps docs.rs/frunk_core/0.0.22/frunk_core/generic/trait.Generic.html is somewhat related?

maybe not...

the term Repr reminds me of that tho

can someone recommend a web framework "most like rocket.rs, but compiles on stable"?

I cannot recommend it because I have never used it, but there's {!crate gotham}

I'm trying to solve this: play.rust-lang.org/?gist=d66e676af6…09e408121374e54c4251&version=stable - How can I pass a shared Service to hyper's .bind() method?

sgflt: i really like {!crate shio}

shio and gotham are on my shortlist as well, thanks

Ok, I give up on Hyper, moving back to Rocket

docs.rs/shio doesn't look nice.

How can I have cargo doc not omit the fields for a struct?

any tips on how to track down a memory leak in my tcp server? I think it might be some futures channels not closing all the way or I'm leaking threads (spawned for each client). I think it might help to name my threads but I can't get prctl::set_name() to work. it'd be great to look at htop and see what the threads are for.

Jasmine: It won't omit them if they are pub

stephaneyfx: They are pub

pub struct LoginRequest { /* fields omitted */ }

from the generated docs^

Jasmine: Hmm weird, they should show up then

oh wait im an idiot, sorry. The fields on the struct have to be pub, not the struct itself

centril: Reading about type families, the word Family seems to fit more than Kind.

centril: trait Family<Index> { type Type; }?

is the users.rust-lang.org login-via-github link broken for anyone else?

rovar: GH is in unicorn mode, so things may be broken.

ah

I did a quick load of a gh project and it worked, so suspected no angrycorns

Hello! Is there a way to apply a procedural macro on an imported type?

So I'm having issues unpacking a `Cow<'a, str>` and translating it into another `Cow<'a, str>` through as_ref() (loses track of lifetime). But not when I do the same as an expression. What Am I missing? play.rust-lang.org/?gist=ebc4ea3ec4…d757b0cbd5b79985661b&version=stable

(Primarily the second part, I can reason that as_ref() doesn't include the lifetime in the signature)

udoprog: the issue is that Cow could be Cow::Owned

ie, it would be String

and in do_stuff it is then dropped at the end of the function

centril: What about s/Repr<Kind>/Instance<Family>/?

Nah that's not it.

in main(), it works because s is dropped after c would be

talchas: Yeah, so the compiler understands that is not the case statically in the expression?

oli_obk_: soon: "make all of libcore const fn" :)

no, it's just that you aren't consuming s

nox: oh my... I've been reading lambda-the-ultimate.org/node/4784 for a long time now

what have you done to me =P

centril: AH AH AH AH AH

the standard solution here is that you'd pass and return &str in do_stuff, not Cow

nox: this Hewitt fellow...

centril: I was wondering why you had disappeared.

nox: =P

"Where Hewitt crosses the line from interesting observation to (sorry) crackpot theory is in turning the correct observation around. ASSUMING proof by contradiction is valid THEREFORE mathematics is consistent. Sure, that's also true, and I accept he has proven this is true ... but he hasn't proven that proof by contradiction is valid in the first place! Everyone else can assume this for the

reasons stated above (sure, my theorem may in future be invalidated by a proof that all of mathematics is inconsistent, but I can live with that). But someone who is trying to PROVE that mathematics is consistent cannot ASSUME that proof by contradiction works."

"So yes, the argument is circular. IF mathematics is consistent THEN proof by contradiction is valid THEREFORE mathematics is consistent."

that is pretty apt

Yeah, of course. Thanks talchas!

how can i create a trait object points to null

centril: something something Goedel incompleteness theorem

Xion_: the most unsatisfying result ever =P

albel727: i'll use it for pointer comparision

in ptr::eq

hmm

I hear std::ptr::null() was going to have where T: Sized restriction lifted

but I'm not sure what it means wrt virtual table pointer and such

you can also just do

eval: use std::any::Any; let x: *const i32 = std::ptr::null(); x as *const Any

and that will have the vtable of i32-Any

much fun

now, if you deref this to invoke a &-method, that is UB, because you have &something pointing to null

but the comparison with a trait object of unknown type probably compares virtual tables too, I guess?

ptr::eq is presumably fine

hmm

eval: use std::any::Any; let x: *const i32 = std::ptr::null(); let x = x as *const Any; let y: *const u32 = std::ptr::null(); let y = y as *const Any; std::ptr::eq(x, y)

yes, it compares vtables

eval: --nightly use std::any::Any; let x: *const i32 = std::ptr::null(); let x = x as *const Any; let y: *const u32 = std::ptr::null(); let y = y as *const Any; std::ptr::eq(x, y)

eval: --nightly use std::any::Any; let x: *const i32 = std::ptr::null(); let x = x as *const Any; let y: *const u32 = std::ptr::null(); let y = y as *const Any; std::ptr::eq(x as *const (), y as *const ())

so that's how you extract the data pointer

by casting to a thin pointer

I don't understand why when I have in build.rs: println!("cargo:rustc-link-lib=ipt");

so the answer is not to build trait pointers but just cast existing trait pointer to thin and compare with ptr::null()

my examples link -lipt fine, but my tests dont

forgottenone: ^

hmm, wait, why is it even necessary

if there's .is_null()

eval: --nightly use std::any::Any; let x: *const i32 = std::ptr::null(); let x = x as *const Any; x.is_null()

forgottenone: ^?

albel727: is_null wont do, since i use trait object equality to skip objects in a vector, but casting trait objects to thin pointer makes sense

hey

albel727: talchas: thank you

nox too

(basically it's his answer :>)

is there a rustc flag to tell it where to find files (for use statement)?

albel727: yeah i missed his answer, thank you nox

I thanked him for you. now he has one excess thank. quick, take it back.

use statement can only use things from existing module hierarchy, I think?

it's not like include in C

(where you have include dirs and suchlike)

#[path="whatever"] mod foo; lets you specify a different name/location

thanks for sparing me the trouble :>

but you shouldn't use that to include library code or things like that

hi

Aadi: hello there

centril: A friend suggested trait FamilyInstance<TypeFamily>.

"a family instance parameterized by a type family"

nox: hmm... trait MyTypeFamily { type Output; } impl MyTypeFamily for usize { type Output = bool; } corresponds to type family MyTypeFamily (self :: *) :: *; type instance MyTypeFamily Int = Bool ;

centril: Hence the 'instance'.

nox: type families are type level functions, but you are making a trait parametric over a type TypeFamily

type families correspond to traits

centril: The encoding reverses the things.

nox: the encoding would correspond to: type family FamilyInstance (self :: *) (typeFamily :: *) :: *

but this naming seems unhelpful to me

(aside note: Rust does not support provide a fallback _ => MyType default case in type level functions yet, but specializing associated types would allow that...)

I read impl FamilyInstance<Specified> for SpecifiedLength as an instance of the Specified family for SpecifiedLength.

Not encoded at all the way it should, but the words seem to fall at the right place to me.

>tfw there's no link to beta/nightly stdlib on docs.rust-lang.org front page ._.

>not even links for different stable releases

where google takes them, I wonder

Magic.

nox: but this encodes __all__ unary type families using a binary type family with an index type for each family as the second parameter

nox: what you are doing makes sense, but the TypeFamily parameter feels ill-named

excited for when emacs and rust lsp work super well

I consider the impls of the trait to be the instances of the type families, and the type families exist only by the fact that the trait is implemented. Does that make sense?

centril: If you have a better name suggestion I'm all ears, but I took note.

nox: Kinda - in this case, FamilyInstance<Specified> denotes a type family * -> * by fixing the binary type family * -> * -> * with Specified :: * so you get * -> * back

Yes, I see what you mean.

nox: given this; I'd name it as such: trait BinaryFamily<Rhs> { type Output; } impl BinaryFamily<Specified> for SpecifiedLength { type Output = ... ; }

or just trait Family<Rhs> { .. }

Why Rhs?

even: trait IndexedFamily<Index> { .. }

nox: right hand side of a binary type level function

centril: But SpecifiedLength isn't the family.

nox: no, the family is BinaryFamily

Ah I see what you mean.

nox: you might not want the full generality in naming, so trait Family<Index> { .. } might work better

You put more importance to the meaning of Trait on its own, while I put more importance on Trait<T> I think.

nox: sure, under the interpretation that you can partially apply the "right hand side" T parameter, fixing the binary type family Trait with Trait<Foo> gives a unary type family =)

but nonetheless, a FamilyInstance is an impl =)

centril: What about dropping all type theory terminology? :p play.rust-lang.org/?gist=7418012836…854fff8e46b292caad6d&version=stable

nox: sure why not, if Phased is accurate for your domain which I assume it is =)

centril: play.rust-lang.org/?gist=d6e2f45cd1…bc14da7689672681c760&version=stable

nox: play.rust-lang.org/?gist=920cca525d…ca530da9728203ac79d1&version=stable

centril: Sent it on #servo, thanks for participating to the bikeshed. :)

nox: it was fun =)

nox: I think the type aliases type CV<TCV> = <TCV as ToComputedValue>::Output; type AV<TAV> = <TAV as ToAnimatedValue>::Output; can really make a difference =)

Yeah.

makes traits feel much more like "normal fn"s

Hello!

hi

!hi @ boomshroom

Is it possible to generate a binary for a custom target? I'm doing some OSDeving and it seems like I can get everything working if I pretend like I'm x86_64-unknown-linux-gnu with some linker flags, but the moment I add a custom target, "error: cannot produce bin..."

I know Phil-opp got around this by building a static library and linking afterwords, but I like not using a Makefile and trying what I can within the languages native environment.

Does anyone have any ideas, or do I just have to resort to a dedicated linking step or pretending to be linux?

maybe #rust-embedded or #redox guys know better

but I wouldn't expect immediate answer, to say the least

albel727: Thank you for your response. They probably would.

hi. i've got a (pretty much arbitrary docs.rs/pgn-reader/0.4.0/pgn_reader…truct.Reader.html#impl-IntoIterator) iterator. how do i process the items in parallel? i've tried using rayon, but it looks like i can't just call into_par_iter() or par_iter()

revoof: You could use `scope` to spawn off a bunch of parallel jobs docs.rs/rayon/1.0.0/rayon/fn.scope.html

as you loop over the iterator

or you could implement doc.servo.org/rayon/iter/trait.IntoParallelIterator.html

which, it appears, doesn't do anything but converting things to Vec and using random access inside that, for most collections doc.servo.org/src/rayon/collections/mod.rs.html#9-17

is there a way in rust proc macros to enumerate all known types that implement a trait?

with the scope & spawn method, do i have to be careful to not spwan too many tasks?

the iterator is likely to create more data than can be collected in a vec

maybe i could spawn N tasks and wait until they are completed before spawning more

centril: play.rust-lang.org/?gist=f2a60de844…90464d576bddb84316d1&version=stable

Hey all. Is there a well known / standard crate for a fixed-size MPSC that removes the *oldest* element if the queue is full?

untitaker: No. Macros work on syntax. They have no type information. The type information does not even exist at the point macros are invoked

neachdainn: so a ring buffer? :)

Arnavion: I remember a weird hack that cbindgen uses: Invoking the compiler twice

but nevermind, I figured out something even dumber to make it work

untitaker: Invoking the compiler from a proc macro is a good way to ensure nobody uses your proc macro

rovar: I imagine it would be backed by a ring buffer. I've written one that fits my bill, but if there's a "standard" one I would rather use that

nox: looks fine to me..? modulo <<T as ToComputedValue>::Output as ToAnimatedValue>::Output which is not very readable

Arnavion: I know

centril: The where clauses on NumberOrPercentage are unfortunate.

neachdainn: there isn't a standard one.. most queues block when they're full, since losing data isn't always a desired feature

:)

I could generate them but only with proc macro attributes which are not stable yet.

nox: ah :(

Hm, is there any way to run just a single run-make test?

remmy: --test-args name_of_test

centril: Do you think it would be reasonable to flow trait bounds from type aliases to data type definitions?

nox: meaning that you add then as where bounds on the type def ?

them*

It depends on how intrusive it gets and if the bounds are natural for the data type itself

centril: Meaning that my code would compile without lines 12-13.

rustc knows which bounds are missing after all.

nox: uhm... do you have the changed version so I can compare?

centril: play.rust-lang.org/?gist=f2a60de844…90464d576bddb84316d1&version=stable Comment lines 12-13.

nox: so you are asking if those bounds are reasonable?

No, I'm asking if it would be reasonable to make rustc just add them silently as part of the RFC for implied bounds.

nox: uhm... implied bounds are afaik about eliding bounds on impls and fns... not type definitions themselves.

Yes, so what could go wrong if it applied to type definitions too?

nox: oh you want to amend the RFC?

centril: Yeah.

nox: I see - is the bound implied here tho?

centril: What do you mean?

so i am working on a service where some people will be building content in html, my system will parse the html, and turn it into some dynamic content. is there an excellent recommended html library for parsing in rust? maybe something like beautiful soup in python?

nox: Number<Specified>: Phased<Phase> - implied?

theobromine: html5ever

centril: I don't understand what you are asking. It's not implied because rustc doesn't imply bounds.

great thanks :)

nox: but if rustc did, why should omitting that bound be legal?

I want it to imply them.

centril: Because it can't do anything without it.

Its definition is type Number<Phase> = <SpecifiedNumber as Phased<Phase>>::Output;,

so I want rustc to imply that SpecifiedNumber: Phased<Phase> when I use Number<Phase> with a generic Phase.

I wrote it as Number<Specified>: Phased<Phase> because it's easier to write down by hand, if that's what you were asking about.

is there a way to get the stringified type path from a TypeId?

nox: no I got that you wanted SpecifiedNumber: Phased<Phase> to be implied... but letting this be implied would lead to pretty surprising code

centril: That's what I want to know about.

untitaker: I don't think so

centril: In general, trait bounds on type definitions are painful for that reason.

centril: If implying them is ok on functions, why isn't it on structs and enums?

where is a nightly release stored, is it on github? I was wondering where to find them and also what 'triggers' the making of the release, is it bors with some command from a human?

nox: because then you have to look into each associated type to see if it carries a bound or not - so seeing if a type satisfies a bound becomes very hard

centril: Ain't that the same for functions though?

centril: Oh I guess it would be pretty bad for private fields in structs.

nox: yeah, that =P

centril: What about it only being implied for public fields?

nox: I think that would encourage public fields too much

durka42: awesome, thanks.

centril: Damn.

nox: also, I think you need to draw the line somewhere so that you have some anchor that is easily checkable

nox: anywho... time for food - laters =)

See you.

Hello i want to make a Rust application with Tokio, do you any idea of application to learn Tokio ?

Onix: chat application?

carllerche: i already did the chat application

Onix: database?

Oh yeah good idea thanks !

is there some pre-made into_enum!(Type, Enum, Variant) macro, that would basically impl From<Type> for Enum { fn from(v: Type) -> Self { Enum::Variant(v) } } ?

I'm trying this new-fangled failure crate, and it appears to miss this boilerplate generation

which I of course could do myself, but if I can avoid copy-pasting that macro everywhere I want it, it would be nice.

Is it possible to use hyper with tokio (not tokio_core)?

I heard they were going to switch to new tokio in the weeks coming. don't remember the actual dates.

I'm working on being able to get tokio-core use the new tokio under the hood

then it should just work

ok, nice.

I have a macro that looks like ` macro_rules! is_char_special { ($($chr:expr),+) => { ... } } `, so you call it like ` if is_char_special!('a', 'x', b') { .. } `

If I wanted to make a macro that was " is_char_not_special ", how would I write it in terms of is_char_special? Specifically, I am having trouble passing the arg list from one macro to the other

grants: you can recreate the list as $(chr),+

oops $($chr),+

o/ is there an equivalent of `npm link` for Cargo?

yoshuawuyts: what does `npm link` do?

durka42: it symlinks a local project into the dependency directory

cargo doesn't have any concept of "globally" installing a dependency so I'm not sure there is a comparison

you can always just put a path in Cargo.toml though to depend on a local project

You might want doc.rust-lang.org/cargo/reference/s…encies.html#overriding-dependencies

not sure if I'm answering the question, the `npm link` man page is gibberish :)

mbrubeck: perfect!

mbrubeck: thank you; that's exactly what I was looking for :D -

durka42: think I found what I needed; doc.rust-lang.org/cargo/reference/manifest.html#the-patch-section

I think I like cargo's approach better, though it's sometimes incredibly difficult to convince cargo to actually replace the damn crate -- but it seems better to do it declaratively, rather than this one-off command that you forget you did...

I need something like `Vec::retain` but I want to be able to return a `Result` from the closure. What's my best bet?

neachdainn: Make the closure return `result.is_ok()`?

neachdainn: hmm what should the result be used for? stop on error?

I have a `Vec<Foo>`, I need to remove the `Foo` from the `Vec` if certain conditions are true, but I also need to be able to return any errors to the outside function

I'm thinking my best/only bet would be to iterate over the indices and do a swap remove?

yeah, I doubt there's going to be anything built in

neachdainn: The closure is FnMut so it could mutable borrow something to store errors which you can inspect after calling retain

hey killercup, is it possible to create a static binary with diesel as a dependency? I'm targeting musl, but my binary still seems to have dynamic deps. I assumed maybe it was the diesel codegenning or something?

*mutably

(or maybe I'm just doing something wrong with the building)

stephaneyfx: That's not ideal, but it's probably way less error prone than the swap remove way

chrisdotcode: With sqlite you can IIRC, you need to add a feature to the sqlite dep though

neachdainn: The body of `retain` is a tricky but short `for` loop: doc.rust-lang.org/src/alloc/vec.rs.html#805-824

neachdainn: You could do a similar loop explicitly in your code

eijebong: so it *is* diesel that is messing with the static linking, yes (and I'm not crazy)?

chrisdotcode: Well I don't think our pg bindings nor our mysql ones support being statically linked

chrisdotcode: diesel-rs/diesel #829 github.com/jgallagher/rusqlite/blob…aster/libsqlite3-sys/Cargo.toml#L15 for sqlite

mbrubeck: That's roughly what I was going to try. I don't know why I didn't think of just copying the code. Hahah

eijebong: ah, so if the pg bindings were able to be statically linked, diesel for postgres would be able to be statically linked?

chrisdotcode: I think so, I'm not sure though

eijebong: is there something I could do to help out with that? my company wants to consider rust, but not being able to statically link diesel for postgres might be a show stopper unfortunately

chrisdotcode: You can look at the postgres bindings, let me find you some links ;)

eijebong: <3

sgrif/pq-sys #4 Actually you can do that already :D

chrisdotcode: ^

eijebong: thanks! we'll try this out and let you know if it we can get it

Hi, what is the difference between dependencies from crates.io and from local paths? Pulling num_bignum from crates.io makes the code 4 times faster than referencing the local copy (same code)

chrisdotcode: Sure :) Always happy to help if you have any question (if I don't because I'm not there, you can also ask on our gitter channel, I'm pretty sure I'm the only one from the usual people answering questions that's monitoring IRC actively)

:)

Oh well, now I found out that local dependencies are compiled incrementally while those from crates.io are not. CARGO_INCREMENTAL=0 gives the performace back, thanks anyway for listening ;)

Seeb: if you notice that big a perf difference (and you're sure it's not you forgot to build with --release) you should file a bug for it on rustc

Seeb: are you talking compile time performance or runtime?

durka42: Runtime, and I use cargo bench so it is compiled in release mode

definitely file a bug about that!

incremental shouldn't cause such a regression

yeah please do! github.com/rust-lang/rust/issues/new

centril: play.rust-lang.org/?gist=388b44810f…ea1042ac2b2d96665fd4&version=stable

nox: so many versions =P

centril: This reduces the boilerplate to `: NumberOrPercentagePhaser` and that derive.

nox: =)

hi, what would be the easiest way to convert a `Result<Vec<T>,E>` into a `Vec<Result<T,E>>`?

rustizer: usually it's the other way around...

durka42: yeah, I know, but I am within a `flat_map` and I need to give it an iterator of results so that the final collect can short-circuit

what would the cases be? either it's Ok(vec) in which case the output is a Vec of all Oks, or it's Err in which case... what? a Vec of length 1 with the error in it?

durka42: IOW, I need to call a function that returns `Result<...>` within `flat_map`

durka42: right, an iterator with one error in it so that it works with `flat_map`

I guess I would just convert it manually then

match r { Ok(v) => v.into_iter().map(Result::Ok).collect(), Err(e) => vec![Err(e)] }

well, you don't need a vec of it, you just need an iterator

yeah that's true but good luck coming up with a single type...

durka42: yeah, the `type soup` is a real pain with futures and iterators, I hope abstract data types or something similar comes up soon

I guess the only way is manually like durka42 suggested

if you can't allocate memory or whatever, you can make a wrapper type around the original Result and impl Iterator on that

eval: let x: Result<i32, ()> = Err(()); x.into_iter().next()

durka42: I can allocate, that is no problem, I just really wish it would be easier to use results within iterators

you might be interested in {!crate fallible-iterator}

which is not /quite/ what you seem to want

it doesn't seem to have flat_map though

talchas: that doesn't work because it ignores the error

yeah

durka42: wow! that is a great crate, what I need, except it doesn't have `flat_map` as you said. Thank you for mentioning it though, I wish it had all the methods that iterators have.

yeah, I don't know how hard it would be to add

shouldn't be too bad I don't think

When you're cross-compiling with -sys crate dependencies, your compilation toolchain should only need the proper library headers right? I realize this is less of a "Rust" question, but I'm viewing it through that lens, and there are a lot of smart people here :P

kehtnok: It depends on the -sys crate

openssl in this case

kehtnok: Crates that need to run bindgen at build time need the headers

which unfortunately seems to have different definitions on Android

WindowsBunny: ah I see, in order to codegen the FFI interface?

kehtnok: Crates which link to libraries the system/user is expected to provide, need the libraries themselves at link time

kehtnok: Yes, many -sys crates already come with the bindings written so they don't need bindgen at runtime, but some do

kehtnok: in openssl's case it's to figure out the build time configuration of OpenSSL

kehtnok: Crates which build everything from source typically don't need anything other than a full cross compiling C toolchain

sfackler: Ah I see - would you have any specific recommendations for cross-compiling openSSL that doesn't involve building the platform specific library for the toolchain environment? japaric's cross project looks really promising but I don't know if we want to go full out if we don't need to

WindowsBunny: thank you for the detailed overview :D really appreciate it

you could grab the openssl install off of your target system and stick it on your build system

you'll need the headers + the libraries

sfackler: Ok so we'll need the full library as well? Not just the headers for the build time?

eys

*yes

is that part of the configuration setup stuff?

(just curioius)

no, the linker needs the library to be there to link to it

at compile time?

yep

Ah... huh. Always thought it'd just need the headers to resolve symbols but not actually load them or anything

has anyone published a good writeup on how to make intrusive collections safe in the absence of allocators?

sfackler, WindowsBunny: thanks for the help!

(i'm considering doing one myself, but if someone has done it already ...)

TIL you can do <Foo<T>>::bar instead of Foo::<T>::bar

that's such a huge lifesaver in a proc macro

jpernst: even in regular macros yeah

very well kept secret

they told us turbofish was the only way!

i thought there was a section in the reference that describes fully qualified path syntax, but i can't even find it anymore

thankfully i vaguely remembered it and decided to try, and it worked

i spend 2 hrs working out this lifetime stuff on something, and it turns out all it was is me forgetting to specify a lifetime on a return type :(

the compiler was right, but boy that was hard to track down

is there an exhaustive list of supported target_arch/target_os/etc.?

glandium: Don't think so. Would be difficult too since it constantly expands

there's this: forge.rust-lang.org/platform-support.html

rkruppe-phone: so, does cfg(target_arch="foo") work?

lgspaw, yeah, nothing freezes the blood like "cannot determine appropriate lifetime for anonymous lifetime '_ due to conflicting requirements"

but it feels great once you finally nail it

jpernst: that was EXACTLY the one i had!

myeisha: what's missing from there is that target_arch="x86" matches i586* and i686*

also, does target_arch="arm" include armv7?

i feel like with the anonymous lifetime stuff, you should get compiler warnings when you dont specify the lifetime

is there a target_arch value that works for across all powerpcs, 32 and 64 bits?

things like that

IOW, this seems way underspecified for something that's stable

can someone explain to me what bors does on github?

glandium: reference states for target_arch: "This value is closely related to the first element of the platform target triple, though it is not identical." - no help there :/

but i understand that the anonymous lifetime stuff is an ergonomics thing, and putting warnings would ruin that

does travis do the same thing as bors?

yeah, anonymous lifetimes are great until they're not

but thankfully, the more you work with it, you develop an instinct for where the problem probably is

yeah

that makes sense

glandium: cfg(target_arch="foo"), literally, does not work. but theoretically might work in the future if someone creates an architecture with that name and rust gains support for it :)

glandium: ("does not work" = is never enabled, you won't get an error)

rkruppe: so you can make typos, and get screwed over. great

glandium: This is nothing target_arch specific, it applies to all cfgs that "have values", including e.g. cargo features

And we wouldn't want to error on it anyway since that would make adding conditional support for a new target architecture break compatibility with older rust versions that don't know that arch

so, rustc apparently takes target_arch from Session.target.target.arch, however that's filled from

Ultimately it comes from the target spec (built in or JSON)

So you wouldn't even need to modify rustc to add target_arch="foo", just write a target spec in JSON :)

pastebin.mozilla.org/9078438 facepalm

and that only outputs for the current target. Is there anything to print out everything the compiler supports? iterating that with the output from -print target-list?

glandium: If you really wanted to. I don't know why you want an _exhaustive_ list though. Since it can expand at any time, and users can add new ones with custom target specs.

rkruppe: because I want to figure out the answers to the questions I asked earlier, and more

glandium: If you have a question about a specific target (like armv7), then try for that specific target.

so, for example, target_arch="arm" does include thumb* arm-* armv4* armv5* armv7*

and it would seem there's no way to distinguish whether you're building for arm or thumb

huh? the llvm target for asmjs-unknown-emscripten and wasm32-unknown-emscripten are both asmjs-unknown-emstripten

but one is arch=asmjs and the other arch=wasm32

can someone explain to me what bors does on github? does bors do the same thing as travis (i.e. CI)?

dbkaplun: bors creates a merge commit and instructs CI (travis and appveyor) to run it, observes the result and pushes the merge commit to master if CI passes.

this is different from the regular travis CI run in that it tests the code that will end up in master, not the current state of your branch (which may be behind master)

Hi. I am trying to find any rules about alignment of struct X { data: [u8; SIZE] }. Would it be portable and not UB to cast from some position in a Vec<u8> to X?