If I want to state that a type should be a unit struct using trait bounds, would Copy + Default be reasonable?

remexre, why a unit struct?

Soni: Do you want to allow other crates to implement RawCommand for their own types?

sleffy: So it can be optimized out, but I have a type to use for type-level programming

remexre, I don't think there's any good way to do that tbh. If this was Haskell I'd say give it a function to any `T`, like, absurd style, but that doesn't work so much here. You could throw in some asserts in places that `size_of` is zero alongside those trait bounds?

stephaneyfx: I am ok with that, yes

remexre: diesel uses tests with size_of to assert that its types are zero-sized. There's no way to force them to be that at compile-time unfortunately

Soni: Ok, so what I was going to suggest does not apply then, sorry :p

what's the state of the art for lexers in rust?

stephaneyfx: mainly I want other crates to be able to use it and read the docs for it, I just don't mind them being able to implement it because I'm not gonna accept their types anyway

(I have a separate function for each valid type)

Soni: I was going to suggest you could get rid of the Unsafe* trait and do something like this to define RawCommand and prevent other types from implementing it: docs.rs/ndarray/0.11.1/ndarray/trait.Dimension.html (look at PrivateMarker). But I understand it's not really what you're after.

stephaneyfx: return mem::zeroed() ?

Soni: It won't work because you won't be able to even write the signature of the method: play.rust-lang.org/?gist=ab705d18b0…9d7a762f25973b1ea481&version=stable

hmm *wonders if there's a way around that*

I'd like to believe rust has associated types for fns so you can write something like AType::fun::Return

Soni: the Fn trait has that, but not in general

can you exploit any of those traits to get an Private?

I didn't read your entire problem, but probably not the way you want to

Soni: No.

ok :(

Any chance that Luminarys on github uses this network? Got some questions about Synapse

can someone explain why lazy_static! changes the type of the variable? paste.rs/2iL

snowe_: you're trying to move the object out of the static there

have new accept a reference instead

danieldg: oh.

it's a library

and I was following the example

where'd you find the example?

that would work if the type were Copy

if the type were copy you could write *COMMAND_BUS yeah

I did copy and paste the code to rename the types, but I don't really understand how it works.

well you'll notice they never try to use the static by value there

it's always either calling a method or &*

what prevents us from doing rust development on iphones, ipads, etc?

and by that i mean compiled on the device itself

what lazy_static actually does behind the scenes is create a new type whose name is your static, and make it deref to the value that you set

so that might make the error message more understandable

oh. ok yeah that does. thanks durka42

theobromine: apple doesn't let you compile code on the device iirc (to include any kind if JIT)

s/if/of/

so if I didn't want to have a static EventBus, then how could I change the code to accept a non-static &self?

referring to this line here.

hmm, what happens if you just remove the 'static

oh, it won't work because it's also 'static on line 45

looking at the comment on line 37, it sounds like you'll have to add a lifetime to EventMetadata and thread that through everywhere

to be able to remove the 'static

durka42: huh...

danieldg: but can't i make a compiler in webassembly and run webassembly in a browser?

theobromine: sure, you can technically do anything

but that's not what I would think of by "developing rust on the iphone"

I mean, you can run Windws XP in webassembly and get IE6 support on your iphone, if you try hard enough

rustc doesn't compile to wasm just yet

clang has, though. so, it's certailny feasable for non-toy projects

you can compile rust code to ios compatbile things already

so in theory you could do it natively with rustc too

danieldg: the "compile code" thing changed a bit. you can't JIT, but you can include an interpreter

durka42: I don't know if I know enough to convert this to not use a static lifetime :(

Does wasm32-unknown-unknown JS interop suck? I've tried that and both emscripten targets and they just won't work

it's very minimal

which can be read as "suck", sure

it's being actively worked on

it will be easy in the near future :)

snowe_: yeah I can't tell from a quick glance whether there's something that blocked Soni from doing it, or if it was just left for later

why do you need it to be non-static though?

durka42: I'm generating code using quote! and it really doesn't like lazy_static stuff

I'm just needing to use XMLHttpRequest, but now when I try to use these targets it doesn't work (vaguely, as it will seem to just do anything to not work)

that's weird, I don't see why that should be incompatible

I just don't know what I'm doing so that's more likely the cause

oh cool. ok i got it working with static.

yeah I just didn't know wtf I was doing.

alrighty! next question. using proc_macro_attributes is there any way to get a function reference?

like, to what function?

from my code before. paste.rs/0Cz

so instead of having to register the function manually, have the attribute do it.

I mean, in your proc macro you should be able to figure out it's a function and get the name

so you can generate that code

but, I don't see how you could get it into main()

oh I see you'd get it into a new fn called bootstrap

yeah no worries about getting it into main.

yeah

i completely forgot i'd be generating tokens

and then letting rust figure it out

alright. I'm back durka42

expected one of `!` or `::`, found `.`

no clue why it thinks I need to be calling ! or :: on COMMAND_BUS

I think you're generating code at top level that should go in a function

ah. hahaha

that's definitely it rofl

thank you

also, I tried to use cargo rustc -- -Zunstable-options --pretty=expanded to output the syn generated code, but it didn't output anything.

so, how would you go about generating code for all attributes into a single function? not sure the best way to accomplish that.

snowe_: so I've experimented with things like this and it's a bit weird because there's order-dependence, right?

like, you want to generate bootstrap() *after* processing all the attributes

and, in my experiment, if you just store all the stuff you want to generate in a lazy_static inside the proc macro crate, and then dump it out in response to another macro call, say gen_bootstrap!(); which you put right at the end of lib.rs, then it indeed works

but I don't know how much to rely on that kind of ordering, it feels fragile

that said, I expect this kind of "register all the things" attribute macro to be pretty common so maybe I've missed an obvious design...

durka42: yeah that's exactly what I'd like to do

ah. so it'd need a regular macro call as well?

dang that's getting a little more hairy...

surely there's another way...

who can we ask?

maybe it's worth posting in one of the proc macro tracking issues / RFCs if nobody else shows up here

durka42: that kind of thing is required for custom test harnesses which I think there's some movement on

I'm writing my first crate using futures, and having a lot of difficulty dealing with typestates - ie, the way that almost everything takes `self` by value. Does anyone know of any crates, blogposts about, or advice for dealing with them more ergonomically?

sfackler: oh?

durka42: ok. sounds good

sfackler: is it even guaranteed that a given proc macro crate is loaded exactly once?

don't think so

durka42: will the derive crate always compile first? like I would put the macro call at the end of the regular lib?

that's what I did in my experiment yeah

really, it's unstable so you can either see it as *nothing* being guaranteed or exactly the current implementation being guaranteed

that's true heh

now I'm thinking of something truly insane like #[path="/some/named_pipe"] mod input;

O_o

You cannot rely on proc macro attributes being expanded in any order over the whole crate, or even being expanded at all

why the "at all" part?

Arnavion: you can't rely on them being expanded at all??

yeah that seems to kinda make them useless...

The mod was already compiled previously and hasn't been updated

ah right

So if the mod hasn't changed and the proc macro hasn't changed, there's no reason to recompile it

so anything like this type of registration facility will need compiler support like sfackler alludes to

In general the only state a proc macro has is its current invocation. Nothing else is guaranteed

Arnavion: so, what I'm trying to do won't work at all?

it *may* work but it also might break with the next version or if you turn on incremental compilation

snowe_: Not with proc macros, no. You'll have to make some kind of pre-processor in a build script

:(

what do you mean by preprocessor?

!gh 2318

whoops

!gh rfcs 2318

^ I guess that's what sfackler alluded to

A test framework is like a whole-crate procedural macro that is evaluated after all other macros in the target crate have been evaluated. It is passed the TokenStream for every element in the target crate that has a set of attributes the test framework has registered interest in. For example, to declare a test framework called mytest:

huh. well that makes sense.

I guess you can basically roll your own proc macros in build.rs by parsing the whole crate and looking for #[register_it] attributes, then generating a module

that's guaranteed to happen before the main crate is compiled

but that kind of... lame :)

yeah there's no way I know enough about rust to be able to do that.

it's similar to what you're already doing in a way

just fire up syn and feed it... everything

and write out a file

but definitely more involved yeah

durka42: do you have an example of your gen_bootstrap method? I am just gonna go with this method and learn some stuff.

yeah, I guess I can throw it up on github

I recommend caution though :p

There is a benefit to the build.rs way, which is that being able to debug macro output is inherently trivial.

snowe_: here github.com/durka/macgen

I haven't commented it yet :/

`cargo expand` shows how it works though

man it really sounds like I should use build.rs...

I haven't learned about build.rs yet though

so would that run against a library user's crate?

no a build script only runs when compiling the crate it's attached to

I guess you could provide a function that a user would call in *their* build.rs

ok, so that wouldn't work either. I want the user to be able to use the attribute.

hm. ok.

and thank you for the github upload. I'm looking at it trying to understand.

I get a lot of 403s clicking on links to tokio.rs from the futures documentation, is that known?

durka42: do you think it would be possible to write a bootstrap method that takes in the users crates and parses them for the attribute?

if that's done in the build script

why does it have to be in the build script?

well... if it's called at runtime how is it going to get the source code

mbrubeck, your robinson toy web renderer - how nice do markdown files look?

lf94: it doesn't do text, only boxes. :P

durka42: oh. I forgot that rust is compiled XD

mbrubeck, big sad face

durka42: could you explain this error then? I tried to modify your code, but it seems I can't store references to the idents

If someone implements a renderer with built-in video support, I think it could be usable

for day-to-day

no javascript required

snowe_: apparently Ident contains a raw pointer?

maybe just store it as a string

I wouldn't be able to have multiple functions with the same name then right?

snowe_: you already can't declare functions with the same name

btw you tempted me into working on the build script hack :)

durka42: even if they take different params? I didn't realize rust didn't have overloaded methods

it doesn't

:(

How long do gists from the playground last?

neachdainn: I don't know if github ever deletes anonymous gists. However soon you won't be able to make anonymous gists, so that functionality will break

That feature is going away? Why?

I have a match arm ` Expression(Value(ref identifier), _) if self.is_builtin(identifier) => self.eval_builtin(*identifier, arguments),

`

is_builtin takes a reference to the type of the match arm

this code as it stands doesn't compile because I can't move the *identifier out of borrowed content

if I get rid of the `ref`, then it fails to complie because I cannot bind by move into a pattern guard, reasonably enough

I'm not sure how to mkae the compiler happy here

I want to move identifier into self.eval_builtin() if is_builtin() returns true

CognitiveRadiation: I am not totally sure without seeing your code, can you do a rust playground cut down version

also there is a little known binding trick you can do that might help?: doc.rust-lang.org/1.0.0/book/patterns.html#bindings

should just not move the value

and give guards a reference

neachdainn: I dunno. Ask github blog.github.com/2018-02-18-deprecat…ce-removing-anonymous-gist-creation

Looks like they are being abused

can rust playground paste stuff from its own account, so as to not pollute mine with random stuff I untangle here for other people?

either that or it could persist it somewhere else

I think it did that originally. probably also got abused :>

haha, make it so that it's only stored if it compiles to rust

the mario maker approach

/* BINARY DATA */ fn main(){}

binary data enlargement pills

bunny floof enhancement pills

Hi, I want to discuss this(rust-lang/cargo #4830) issue here for a moment. It's a issue in cargo.

Person who reported issue ran, cargo install --force --bin svgcleaner --git github.com/RazrFalcon/svgcleaner and got an error that says "Multiple packages with binaries found"

The --bin flag is to give a binary name and packge names are taken from cargo arguments

What is the use of --bin package?

*I meant --bin flag?

How can 1 package have >1 binaries?

Nvm, Found this question on stackoverflow, stackoverflow.com/questions/3660401…-build-multiple-binaries-with-cargo

So, I guess, That github issue is because of misunderstanding and not an actual issue in cargo.

albel727: I may be missing something, but where did you make the playground not create anonymous gists?

Hey I'm having trouble using the crate quick-error. If I include it in the toml as quick-error, it's found but cant be found from my code as extern crate quick_error. But it's not found as quick_error in the toml

nox: it was speaking about the near future (~2 weeks), when github forbids anonymous gist creation.

Oh ok.

Um, Is there really no package to encode/decode base64/hex in rust?

*Is there no package in std lib to encode/decode base64/hex in rust ?

!crate base64

ishan_: doc.rust-lang.org/std/primitive.usize.html#method.from_str_radix

(for hex)

!r

...

I have already found those. I am solving some questions and they don't allow external crates. I wish, base64/hex were included in std lib.

then.. write it yourself?

or copy it

ishan_: hex *is* in std

not allowing crate is ... just stupid

sebk: That's what I am doing now.

sebk: I hope they never ask to do HTTP requests

:D

glandium: it is not *that* complicated

you can actually do it with plain tcp

can I see the asm of a specific function in rust playground?

!godbold

sebk: I've done my fair share of HTTP requests with telnet back in the day.

!gb

liranringel: try this godbolt.org

liranringel: rust.godbolt.org

!learn godbold = rust.godbolt.org

oh. -t

!godbolt

!forget godbold

!godbolt

it doesn't know godbolt either

!learn godbolt = rust.godbolt.org

liranringel: use #[crate_type = "lib"]

and then pub fn test() {}

godbolt doesn't need to explicitly set the crate type

I'll try it now!

Godbolt is so good.

How do I split u8 slice? I tried <slice>.split(10) but this gives an error that says, "for <'r> u8: std::ops::FnMut<(&'r u8,)>` is not satisfied.

ishan_: split how? For example the .split_at method splits a slice into two parts

I read a file using include_bytes!(), It gives me a u8 slice. I want to split the content of file at every newline character.

if you want to split it with the value 10 as delimiter, then you chan use .split(|elt| *elt == b'\n')

since split takes a closure

Thank you so much @bluss.

One more question, Usually, I pass a integer or a string in split(), Are those automatically interpreted as a closure?

Why wouldn't using b'\n' or 10 as u8 in split() work in this case?

is it possible to ptr::null() to object reference

I mean struct reference

forgottenone: you want to set a reference to null?

myeisha: yes, just as a placeholder

forgottenone: no, but you can use Option<&T> and None

myeisha: i see thanks

ishan_: there's no such automatic interpretation as a closure for .split() on a [u8]

ishan_: maybe you're thinking of str::split (string slices), which accepts more than just closures

I got an error[E0225]: only auto traits can be used as additional traits in a trait object in my code: play.rust-lang.org/?gist=3a9865aae3…b3a0f07d0a9d4bb0d02e&version=stable , but I don't know how to resolve it. I want to save a hashers object list, and get hash result with a hashable item

sbw: Hasher + Sized becomes a self-contradiction and it doesn't resolve this

sbw: Box<Hash> implements Hash and is sized, so it can be used for this

but one must also keep the semantics of the hasher state in mind (and the mut makes that more clear to us)

if you want to compute a new hash, you need to reset or recreate a Hasher value

(and by Box<Hash> before I meant Box<Hasher> implements Hasher, sorry)

ok, I will try this

I think to solve the reset/recreate hasher, you'll need to define a new trait for that functionality (and implement it). I guess basing it on Clone would be the easiest, so not a reset but a create new functionality (but still needs a new trait with a helper method)

I'm wondering if anyone can help me with this baffling AsRef issue.

I have a function with this signiture: fn run_command<S>(&self, program: S, args: &[S]) -> Result<Output, Error> where S: AsRef<OsStr> {

and when I call it like run_command(command, &args[..])

where args is a Vec<String>

I get this error

| 41 | self.run_command(command, &args[..]); | ^^^^^^^^^ expected &str, found struct `std::string::String` | = note: expected type `&[&str]` found type `&[std::string::String]`

I thought asref was meant to allow you to take both &str and String?

nevermind, both program and args have to be the _same type_

kindiana: yeah

kindiana: you can do S1, S2 of course

Hi! I've got a question about the reql crate (github.com/rethinkdb-rs/reql). How can one reuse the same Client, tokio Core and reql connection? Feels like a waste to spawn them every time one must sent a message to the DB. Also AFAIK having a DB connection in a global, shared variable is neither attainable nor desireable in Rust. I'm sure this question is valid also for other DBs and things you want to keep a living connection

to...

Do sideeffects inside debug_assert! happen in release mode? I.e. is debug_assert!() in release compiled to nothing, or is it just the panic that's removed?

Basically I want to do `debug_assert!(do_something().is_ok())`

Mateon1: The code inside doesn't run at all when the debug assert is disabled

Ok, so I need `{ let x = do_something(); debug_assert!(x.is_ok()); }`

yep

but the code inside is compiled, in a disabled branch, in any configuration. So it is still type checked

and borrow checked etc

is there a way to create undef from Rust?

let a = mem::unitialized() maybe ?

gnzlbg: It's not generally safe to do that. What are you trying to do exactly?

I am calling an llvm intrinsic and need to pass it undef

gnzlbg: Then you probably want mem::uninitialized indeed.

is that what mem::uninitialized does?

there is undef and then there is poison

gnzlbg: mem::uninitialized returns uninitialised memory that is sound to write to but unsound to read from.

and what codegen does it generate ?

*code

undef, IIRC. Check on the Playground or godbolt.

thanks will do

i will give it a try and just check the ir

cargo llvm-ir foo :D

scan+flatten aka flat_map(|x|x) should be made more popular

it's literally the best way to parse strings

or any data

What

That's a pretty bad way to parse that.

I'm confused by a compiler error, and was hoping someone might know what's going on. I've got a function which specifies that a type P: Pixel, but when I try to use an associated type from this trait the compiler complains that P does not implement Pixel. Code here: gist.github.com/theotherphil/5d05669f5fc116100448f28c5bfee55f Any ideas?

theotherphil:

<P as Pixel>::

try that

gnzlbg: That's what they have…

I tried this after the first error - this is the last line of the gist, and the line that the compiler is complaining about (possibly not that clear from what I pasted)

theotherphil: AH

theotherphil: Does Subtype has a default in Pixel's definition?

I've seen something like this before with incompatible library versions, but I've deleted my lock file

<P as ::image::Pixel<Subpixel = u8>> ?

Either ::image::Pixel ≠ Pixel, or Subpixel has a default and rustc gets confused.

nox: I don't think it does - docs.rs/image/0.18.0/image/trait.Pixel.html

you are requiring P: Pixel<Subpixel = u8> but then trying to access it as <P as Pixel> instead of <P as Pixel<Subpixel=u8>>

nox: what's wrong?

Allocates strings for nothing, and the code flow is very hard to follow in your snippet.

gnzlbg: That shouldn't matter.

gnzlbg: Then it might not be the Pixel trait you are looking for.

it can matter if Subpixel uses associated type defaults

Which it doesn't, they just linked to the trait definition.

nox: I didn't feel like writing long-form

gnzlbg: how would I fix this? The compiler rejects <P as Pixel<Subpixel=u8>>::channel_count complaining that it's not valid to specify an associated type in this position

Soni: And that's fine, but that certainly doesn't make it "literally the best way to parse strings".

theotherphil: Are you 100% certain that Pixel == ::image::Pixel in your code?

nox: it is the best way if you use long-form

Soni: No.

And you just said you *didn't* write "long-form" (whatever that means),

so now you are contradicting yourself AFAIK.

let me write it long-form. still needs scan+flatten tho.

There is no need for either of those things to parse strings or any other kind of data.

nox: there are no other Pixel types around that I know of. <P as ::image::Pixel>::channel_count still complains that P doesn't implement image::Pixel

If you're writing a parser "long-form" whatever that means, you want to write a state machine.

theotherphil: if you leave the part that errors out, does the code type-check ?

lol: <P as Pixel>::channel_count() as usize

you are using that here [val; <P as Pixel>::channel_count() as usize]

that's not going to work, trait methods are not const fn

and even if they were, you wouldn't be able to use them to create a new type inside a function like that

gnzlbg: Oh right, hah!

the error message is pretty bad though

I wonder why the compiler is complaining about P: Pixel though, that feels like something is misinterpreted in that const context.

Yeah.

probably it hasn't done trait resolution yet

or it is not even taking it into account while trying to project the array type

it must have done trait resolution and checked that P: ::image::Pixel

so it is more likely that the logic for consts does not account for trait methods / traits in general

gnzlbg: as written it doesn't type-check. I've replaced the bits it's complaining about with a constant and fixed the rest of the type errors. It now compiles with that bit commented out, but doesn't when I uncomment it

associated consts cannot be used in that position either

theotherphil: what you are trying to do cannot ever work; do you understand why?

gnzlbg: I don't. I've done something that looks identical to me elsewhere and that worked

that's a minimal working example

you are trying to create a new type inside your function: [i32; <P as Pixel>::channel_count()]

channel_count is a dynamic function

but the array length must be known at compile-time

gnzlbg: ah, this works if I replace that with vec![...]. Which is what I intended in the first place. I was just totally misled by the compiler error message

yeah that works

Sanity check: the compiler error here is nonsense, right?

If so I'll add it to the thread in rust internals about compiler error complaints/requests

Thanks for the help

it might be a duplicate, but i couldn't find anything similar

Ah, great, thanks!

gnzlbg++

hi, how easy is it to marry rust and python`

and is there xslt and xsd support?

ray: lots of people are doing it, there's tons of crates to make it easier, like milksnake and pyo3

i haven't done much xml processing so i know there are generic xml libraries but not sure about xslt/xsd

unfortunately stuck with xml for various things

currently using lxml for these tasks

ray: see developers.redhat.com/blog/2017/11/16/speed-python-using-rust and blog.sentry.io/2017/11/14/evolving-our-rust-with-milksnake

for example

ray: well, there is a lxml wrapper

!crate libxml

steveklabnik: doesnt look like it ships with xsd and xslt bindings

gotcah

yeah

i see that now

i know xml is unpopular these days

welp I ended up writing the build script proc_macro_attribute hack that snowe, Arnavion and I were talking about last night github.com/durka/macbuild

oh

if you are writing softare professionally however everythings full with xml

looks like shep has some libraries github.com/shepmaster/sxd-document

which thread pool crate would you recommend? (not using futures, not scoped)

e.g. sap idocs and soap apis

github.com/shepmaster/sxd-xpath doesn't have xslt support yet

SovietBear: i still prefer scoped threadpool. it's like 150 lines of readable code

even if you don't plan on using the scoped aspect, it's still good, imo

steveklabnik: can it do non-scoped threads too?

scoped threads are a superset of non-scoped threads

no?

steveklabnik: why am i not getting the backtrace from the original panicked thread? pastebin.centos.org/572586/09415715 (the one that caused "attempt to subtract with overflow")

steveklabnik: btw, github.com/shepmaster/sxd-document#overview

"In the future, I hope to add support for XSLT 1.0."

tl;dr no xslt crates available i guess

i should take off a year from work and implement xslt 3.0 xD

if i could

ray: you could crowdfund it

or find a company as sponsor

yeah, was joking, no idea if i could manage to get the full parser implemented :)

ray: yeah, i'd be nice. rust is still young, so the long tail of libraries is filling out

yeah, i guess it will take another 2-3 years until you can consider using it

i mean

how big is the libxml api surface here?

you could bindgen it up, maybe

it's not the *nicest* thing

yeah, thats probably the most feasible thing

everyone's stuck with libxml bindings

which were up to date around 2000

there's saxon C saxonica.com/saxon-c/index.xml which is somewhat more up to date

would someone be able to explain the difference between linear and affine types to me? (:

cheers-M: so

linear: must be used exactly once

affine: must be used at most once

1 time vs 0-1 times

that's it

SovietBear: i am not sure, tbh.

steveklabnik: when another non-main thread crashes, i DO get the backtrace from that thread, just not with this one

oh, alright. i was reading a discussion where people were talking about the two as if there were other differences

but they are spawned the same way

or perhaps certain properties granted by their attributes. safety guarantees etc

anyway, thanks!

cheers-M: it's also hard because some people call both "linear"

ah. strange

steveklabnik: how can i find out why i'm not getting the backtrace?

i don't know

SovietBear: What platform?

WindowsBunny: windows 8.1

SovietBear: So you're saying a thread is panicking with subtraction overflow, and your panic hook isn't being run on that?

WindowsBunny: right

WindowsBunny: gist.github.com/Boscop/f55be5269a47b2bd04b5bd99c19928e9

Hi there I'm having an issue with values not living long enough in function. I have a data structure that contains elements and I wanna get a reference to that element and return it how can I do it? Here is the code I have at the moment

SovietBear: I can never remember that you and Boscop are the same

SovietBear: I'm not entirely sure

WindowsBunny: is this a rustc bug?

I honestly don't know

How would I move all values in an array by one index? I currently rely on cloning the values, but maybe it'd be possible to optimize it.

you could do something with swap

if you've benchmarked it and it's a performance bottleneck, you could use unsafe code to make sure you don't do unnecessary (shallow) copying

oh, that could definitely work

(since I would be surprised if the optimizer managed to turn a swap loop into memmove)

hopefully it gets optimized even further by the compiler, but I'm satisfied even with just using swap instead of having to clone the values. Thanks!

albel727: ArrayVec has that IIRC.

hmm, it does.

nox: told you I'd write it long-form play.rust-lang.org/?gist=d143902040…dae20d896f4ea9eb4701&version=stable

just for you

I have no idea what you mean by that gist.

nox: I turned this: bitbucket.org/SoniEx2/wcc-rs/src/e0…er=file-view-default#lib.rs-147:157

into that[

You may be interested in reading literature about implementations of parsers, because that was vastly unneeded.

oh hey it's Soni! did you ever rewrite this without the static requirement?

snowe_: I have abandoned my eventbus because I don't believe events are the way to go for something like rust

ah :(

you're welcome to fork it tho

maybe when I get more comfortable with rust.

heh, that looks familiar

right now I don't even know how to solve this error. paste.rs/p76

&fun_list?

didn't work either.

uh huh

what

tried #rust-beginners ?

i'll try over there

fn(&mut T) doesn't implement Hash + Eq

not that I'm seeing a good reason for that

other options: find someone who has created a high-performance, extensible event bus in rust

What's the future of box_patterns exactly?

It's been in nightly for a long time, it seems

emerentius_: is there an alternative to what I'm trying to do then?

Unable to negotiate with 172.17.0.1 port 52374: no matching host key type found. T

oops, sorry

snowe_: you could write a newtype around the fn and manually implement PartialEq, Eq and Hash for it

in terms of the fn's address, so through a 'as usize' cast

o.O

annoying boilerplate but it should work

I'm wondering why "impl<Ret, A> Hash for fn(A) -> Ret" doesn't catch A = &mut T

?Sized?

(maybe?)

(I have no idea what I'm talking about)

&mut T is Sized

emerentius_: so the docs say that fn implements hash, eq, and partialeq so I don't really understand what I need to do.

does Box do more than new/malloc?

or just use Box whenever you'd have used either one in C/C++?

snowe_: looks like a bug in the trait system

O.O

i would hit a bug as soon as I try to start using rust again.

snowe_: seems to be an interaction with the higher ranked trait bounds

this for<'r> fn(&'r) stuff

How would one instantiate a Box<DST>?

is that in the doc somewhere?

I'm filing a bug

oh! awesome.

you're sure it's a bug?

well that sounds exactly like what I'm dealing with.

it is

What's the best way to get the pthread id (pthread_t) from the currently runnign thread? I can only think of let id: pthread_t = transmute(thread::current().id())); I hope there's something better.

trait EnsureEq: Eq {}; impl<'a, T> EnsureEq for fn(&'a T) {}; works

it's the HRTB that break it

Moomoc: there's no guarantee that .id() has anything to do with the platform's thread ID

occultus: I know, but my code is specific to one platform anyway

not that it's actually a trait bound

occultus: So is it acceptable in this case? Any alternative?

occultus: I need to hand something over to the C pthread interface

emerentius_: like this? paste.rs/6jV

that still results in an error for me.

Moomoc: actually, it might be guaranteed to *not* be related

snowe_: that doesn't implement anything, it would result in a compile error if fn(&'a T) wasn't Eq

occultus: How that? I looked into std and there it is struct ThreadId(pthread_t).

Moomoc: thread::current().id() was "1" when I ran it, which is definitely not the pthread id

emerentius_: I don't really understand...

it's like a type level assert!

EnsureEq requires Eq to be implemented

occultus: On which platform are you? There's an implementation for Linux and one for unix, I'm using the unix one on my platform.

but implementing EnsureEq doesn't give you Eq

Moomoc: Linux here

use the libc crate to get the pid?

Moomoc: if you're calling into C already, why not just use the pthread interface?

emerentius_: oh so you are saying that Eq has to be implemented since that code doesn't fail to compile.

Moomoc: the problem with using ThreadId directly is that a future version of Rust might use something that is not the pthread id, breaking your code

occultus: ah right. I didn't think about that. Do you know by any chance what the name of the pthread function might be to get the handle for the current thread?

occultus: yeah, that absolutely makes sense.

Moomoc: pthread_self returns a pthread_t

snowe_: yeah

fn(&T) is really for<'r> fn(&'r T)

but fn(&'a T) is just that

I managed to build a HashMap of reference taking functions at least

You might be able to sprinkle generic lifetimes everywhere and have them adapt to whatever's necessary

given that they're not bound to anything

might also break on sth, I don't know

occultus: Indeed, pthread_self() is what I really want. Thanks! I was just trying to get a handle to the main thread. Thanks for the help

but lifetimes subtype so whatever the smallest lifetime is that any of your functions take

longer lifetimes are also acceptable

emerentius_: I understood some of what you said

snowe_: treat your HashMap<fn(&mut T), i32> as a HashMap<fn(&'a mut T), i32>

add a lifetime parameter to your functions / traits as necessary

durka42_: Now build your own cfg-handling so that you can understand #[cfg]'d mods ;)

actually, lemme check if this could work in some simple cases

could very easily fail

Arnavion: noooooo :)

Arnavion: also macro-generated mods in general won't work obviously

how do I use rustup to download the stdlib src for the stable toolchain? I only seem to have it for nightly

emerentius_: man that change is propogating so far through this code...

doesn't work anyway

emerentius_: how'd you test?

Noldorin: If you added the rust-src component it should download the component for every toolchain. If it didn't for any non-default toolchain, try reinstalling the toolchain

maybe Arnavion knows

snowe_: ICYMI github.com/durka/macbuild

durka42_: > This code is bad and you shouldn't use it!

XD

yeah I stopped with the macro stuff just to get the rest of the library going, and I was gonna come back to your code later

but of course I immediately hit a bug in the trait system.

snowe_: made a map with the build_hashmap I posted before, inserted a `fn foo<'a>(&'a mut u32)`, got it back out and tried to call it

couldn't

Arnavion, hrm. just tried, no luck. something special about how VSCode interacts with it maybe?

Noldorin: If you mean rls, rls has never looked in the right place for rust-src for me

Arnavion, yes sorry, rls

Noldorin: It always tries to look under the workspace directory instead of where it actually is

Arnavion, oh right. how did you configure?

I see...

snowe_: play.rust-lang.org/?gist=e6124b62ea…26d30b5406f650b526b3&version=stable

emerentius_: Oh!? you couldn't call it?? why would that be?

Noldorin: I didn't. I left it broken. I know that people have made symlinks in their workspace directory to make it work

snowe_: it inferred a minimum lifetime that the data I supplied didn't have

Noldorin: rust-lang-nursery/rls #227

anyone know of a library for interning strings that supports interning a &std::path::Path (string-cache and string-intern both seem to take an &str, which is problematic since paths are not guaranteed to be UTF-8; they are just bytestrings)?

Arnavion, thanks

I think maybe docs.rs/hashconsing/0.9.0/hashconsing might work but I'm not sure

emerentius_: oh that's without specifying a lifetime. I thought you had specified a lifetime. Would doing what you said earlier work then?

snowe_: the link is the workaround, not the failing test code

ah just found docs.rs/internment/0.3.4/internment/struct.ArcIntern.html

emerentius_: ah.

emerentius_: that results in a very strange error on my side. paste.rs/ULR

is there a stable way to deallocate a box without dropping the contents (unsafe is fine)?

jpernst: I don't think so - at least not without doing something very exotic. If you can control the box though, you could put a ManuallyDrop in there. Or if not deallocating the box is fine, you could forget() it

yeah, i was hoping to avoid manuallydrop, but oh well, no big deal

that means i'll have to make a newtype wrapper, which i really didn't want to do

i guess i could just manually add a drop flag to the struct

jpernst: std::mem::forget(*box_)?

hmmm, what emerentius_ wrote could work - it moves the contents out, and then deallocates the box - then you just forget the contents

hmm, yeah

that's good, i like that

snowe_: I need more context for that, what's Command and what's the signature of register on COMMAND_BUS

this is all a workaround for lack of emplacement, but you gotta do what you gotta do

emerentius_: here is the entire codebase. github.com/snowe2010/pes

urg :(

I tried turning on the warnings for in-band lifetimes

it also warns for code in #[derives] :(

how do i know for which generic parameter i should use an assoc type rather than a type parameter?

is there a rule of thumb?

ray: If the caller controls it, it's a type parameter. If the implementation controls it, it's an associated type

ray: For example, an iterator of T can only be an iterator of T, so Iterator::Item is an associated type

snowe_: are you saving f in CommandHandlerId?

any by f I mean the fn(&mut T)

emerentius_: all of that code was copy and past from Soni's library, so I'm not sure what is meant to happen.

Arnavion: but isnt an iterator of T Iterator<T> ?

I mean it was written back in rust 1.0 or so

so uh

y'know

:p

XD

ray: Iterator does not have any type parameters. Iterator::Item is an associated type.

ray: For the reason I wrote.

so you basically hide the parameter inside the type because its irrelevant to the user?

ray: It's not irrelevant to the user. It's just out of the user's control.

how could the user control Iterator<T>

They can't. That's the point.

you cant make an Iterator<User> to an Iterator<Database> anyways if you iterate over a list of databases

What crate should I use for a config file for my project?

I'm not really sure what style of config file I want

because a List<Database> always returns an Iterator<Database>

ngc0202: Rust projects usually use TOML or JSON, both using serde

Definitely not JSON :)

yeah I guess TOML works

I really just need key-value, value being mostly numbers and sometimes lists of IP addresses

Arnavion: basically i dont know what "the user controls controls the parameter" means

ray: if Iterator were generic you could make a struct that could return different types on calling .next()

i see, so there's a fundamental difference between interfaces in java and traits in rust

stuff looks like methods but its really just a function

how are TOML sections represente n the decoded struct?

emerentius_: you could do that by defining different impls for the struct based on the Iterator type right?

(someone please tell snowe_ to use someone else's library thanks)

like impl Iterator<String> for Vec<String>

impl Iterator<Integer> for Vec<String>

yes

haha Soni I tried to use this library github.com/bonifaido/rust-eventbus but it didn't have metadata and I thought metadata was a good idea.

ty, took me maybe a year to get this :)

ngc0202: a toml section is just a key whose value is a table

Is there a reason that `Any` does not have `downcast_*` for `Any + Send + Sync + 'static`, only `Any + Send + 'static`?

Is it unsafe to have `Any + Send + Sync + 'static` and` downcast_ref`?

Ralith: ahh, interesting

I mean, I assume there must be a reason

I can make a struct and impl Deserialize for it, and just pass it the config file, and it'll come out all nice, right?

ngc0202, toml/serde? Yes, with some restrictions.

what kind of restrictions?

ngc0202, there's some table ordering stuff iirc

I don't remember the specifics. They aren't very troublesome, but in some cases you'll need to add some annotations

ray: I'd *love* for someone to help out with SXD

I think that Rust could be a wonderful language to deal with XML

indeed

shep: and throw out all the xml madness

like get rid of xinclude, entities

shep: whats the difference between this lib and xml-rs

ray: last I checked, xml-rs has no concept of a DOM

shep: my experience is: writing shitty compilers with yacc in university courses, a lot of java/python/js/php and very little C/C++/Rust

also 2 small kids and full time job ;D

it was just a pull parser. SXD has a pull-parser internally, but also a DOM, and most of XPath 1.0 is in sxd-xpath

shep: did you check newer xpath specs?

I've skimmed them

But they went from like... 50 pages to 300 pages

must be the reason why the libxml guys gave up

Yeah, I think maybe only one of the Java libraries has anyting past XPath / XSLT 1.0

saxon afaik

there's some neat things in there, but it seemed like it was way over engineered

ray: there's even some very fun parts of XML + Rust that remain, such as really supporting Serde

oh, we're already at xpath 3

collection()/(let $a := . return function() { $a })

looks like they've built js into it

right?

XPath: not even once

the sad thing is that all standards supported by libxml are lacking

almost impossible to not run into issues when using it

steveklabnik: where is the revised version of this logo? b.thumbs.redditmedia.com/W8uCVAhOkN…hF9AyYvJZrvPJLexMQEpjyzA4Xw2F9A.png what's the current state?

shep: did you look at xsd 1.1 yet?

ray: I've also discovered that libxml doesn't validate that element/attribute names are even valid

like, IIRC, you can say an element name is `\1ha\2`

shep: w3.org/TR/xmlschema-0

looks doable i guess

I havne't looked at it in a while, TBH

what would be a benefit of xml parsing rather than rewriting something to JSON? is it just more expansive?

ray: you think you'd be interested in contributing? If so, we can find something interesting and work up some mentoring instructions

quasikaote: there's a lot of xml floating around

shep: sure, but i have very little time

quasikaote: for *new* stuff, probably not much, but, yeah, interoperation

is there a guide for making links to other items in rustdocs?

quasikaote: xml can do neat things sometimes like reformatting xml is neat with xslt

quasikaote: and sometimes JSON is too weak

snowe_: metadata is just a weird thing that probably doesn't improve performance at all but I tried

hmm. Maybe I'll look into it more once I get more of rust down. I know Openbox uses XML for menus and stuff

a lot of madness went into js which in turn went into JSON

Yeah, XSLT is a pretty great tool, for what it was *designed* for. It's also used beyond that and it's real bad there

like everything that has anything to do with numbers

yeah, I admit, XML is much easier to read than JSON for me

i really like JSON but there are some valid use cases for XML as well

hmm I'll do some research into that stuff. I kind of need to pick one or the other and focus on it. I didn't realize XML was still being used these days

I think it's totally fine to use JSON in new stuff

you need XML for older SOAP apis or for SAP integration

The only things "missing" from JSON are comments and (IMO) namespaces

basically if you are building webshops you cant get around it

and the silly restriction on trailing commas ;-)

lol. good to know.

XPath can also be useful for HTML world

although XML and HTML are further away than is wonderful

right, its like a better version of css selectors

there's some latent interest in getting sxd-xpath to work with html5ever

but I've never really looked into it in detail

can I link to the std doc from my docs

sure

what would that look like?

a normal markdown link

oh, wait should I use the online doc url?

shep: I'll play around with your lib a bit

try if i can get something minimal with XSD going

ray: You may be interested by the Transit format, btw.

(Or not, which is fine too.)

shep: Was it really '\1ha\2' or just an example?

shep: CSS selectors are all you need on the Web, XPath is unneeded.

nox: I'm pretty sure it was a ASCII control character, but I don't remember which

Also, CSS (until maybe CSS 4) doesn't have a "go back up", which XPath does

shep: Ack! Was just curious. NameStartChar is surprisingly large w3.org/TR/2006/REC-xml11-20060816/#NT-NameStartChar

shep: What do you mean by go back up?

/a[../@id = 'moo'] ("find all elements named 'a' that have a parent with an 'id' attribute of 'moo')

that example is rewritable

others are not

lemme see if I can remember one..

shep: Ah I remember, but I can't remember the use case. :)

But I do know that capybara (popular Ruby HTML testing framework) translates all CSS selectors to XPath

shep: "For example, the following selector matches only <a> elements that contain an <img> child: a:has(> img)"

Before that, you could select the img but not the a.

is that CSS 4?

Yes.

CSS 4 isn't a thing though, that's selectors level 4.

true

I get lazy in terminology ;-)

No problem. :)

shep: Yeah, I disagree on some points. :P

shep: I had w3c/csswg-drafts #1027 in mind because :matches() is a pain to implement.

btw, I'm missing something like: cargo add package

ray: before I forget, please feel free to file an issue on sxd-document / sxd-xpath if you'd like to try something, and I'll give as much help as I can!

ray: to add it to your Cargo.toml?

yes

meh :D

i kinda hate the nodejs philosphy

`cargo install cargo-edit` `cargo add foo`

ray, shep: I diss XML because I do a browser where it's not all the rage anymore, but I do realise tools are needed anyway so props to you for working on that.

ray: There is a cargo-add on crates.io IIRC.

!crate cargo-add

Oh.

Disregard me.

nox: yeah, there are some really bad things in xml

but it serves as a warning to other people :D

ray: Dissing it is all great and fun until the bank that processes your payments insists on using XML.

or your health care provider has XXE vulnerabilities

Soni: oh you were attempting to use it to improve performance? in most event sourcing frameworks, metadata is used to add information to every event, like timestamps, tenant identifiers, etc.

snowe_: "metadata" is info about the event type

that stuff just goes on the event instance themselves

instances*

hmm. not in my experience, but if that's how you were using it then it makes more sense why those methods were being called in post method

how come the rustdocs doesn't show anything at all regarding my #[derive(Deserialize)] on this struct

ngc0202 it is a rustdoc bug rust-lang/rust #36922

huh, ok

Soni: why did you decide an event weren't the way to go in rust?

snowe_: I prefer "composition" nowadays (that's not the right term but w/e)

like actors?

events are useful if you need modules

what I'm doing now is useful if you need modularity

rather than using events to parse IRC messages, and having IRC messages natively extensible, I'm actually going for a much more modular approach, where I have IRC messages made up of multiple parts

and there's a trait for a simple RFC-compliant IRC message

ok. I think I understand.

but you can build "trait Ircv3Message: IrcMessage {}"

and so on

and then those can be further refined

and you provide crates with basic impls

gotcha

so there would be a crate for a full IRCv3 implementation, separate from the IRCv3 traits, and so on

and someone could come along and make a crate with an IRCv3 + CTCP-S implementation

it's not as flexible as events but it's much more performant

you can even have subroutines to parse basic IRC commands, also in a crate, in a way that any crate/implementation can use

it's a tradeoff between runtime flexibility and performance

altho if anything, this increases compile-time flexibility

and I feel like the rust way is all about compile-time

yeah you lost me

sorry

maybe it's just what I'm doing that shouldn't use an event system

I'm having some issues compiling my program due to "undefined reference" errors being thrown by a library which uses bindgen. Specifically, the library is "rust-hyperscan"

I've verified that hyperscan (the c library being bindgen'd) has been installed correctly and that it links (ran gcc -lhs)

Shayanjm: you need to link it into your rust program, bindgen doesn't take care of that

emilio: isn't that what this is doing?: github.com/flier/rust-hyperscan/blob/master/build.rs#L97-L102

here's the error in question: gist.github.com/shayanjm/c634bb257fb04f2fae43141035dee846

If I don't pass HYPERSCAN_ROOT, it throws an error saying that hyperscan isn't installed. If I pass HYPERSCAN_ROOT, it throws a whole bunch of undefined reference errors.

hi all, I'm trying to wrangle with some lifetimes, and I've managed to reduce my question to a small example: play.rust-lang.org/?gist=7d57b19235…ef6af9aa615fecbf8236&version=stable . can anyone help me understand why the borrow check fails if line 6 is uncommented?

also ldconfig -p | grep hs seems to output correctly so I'm not sure what's going on

Shayanjm: looks like `HYPERSCAN_ROOT=/usr/local` should work, looking at that code

let me try it, give me one sec

same undefined reference errors

I don't even know how to reason about this :\

Shayanjm: hmm... looks like it's trying to call `_hs_scan` instead of `hs_scan`... can you look at the generated bindgen output? Also, is this windows by any chance?

Nope, this is CentOS7

hm, chaining methods sometimes leads to "does not live long enough errors"

is that a non lexical lifetime issue=

and yeah gimme a sec

ray: good question, I'm not sure

ray: depends on the methods ;-)

e.g. let doc = parser::parse(xml.as_str()).expect("Failed to parse"); works

let doc = parser::parse(xml.as_str()).expect("Failed to parse").as_document(); doesnt

emilio: is my assumption right that the bindgen output would live in src/raw_bindgen.rs?

ray: as_document returns a value with a reference to the value returned by `parse`

Shayanjm: ooh, I see what's going on there... So it doesn't run bindgen at build time, but checks out the bindings...

Shayanjm: one second

`pub struct Document<'d>`

mib_kmvjos: so the issue with `Cow<'a, Foo<'a>>`, is that you're telling the compiler that the lifetime of the `Cow` and `Foo` is the same

Sounds good, and thanks again for your help on this emilio. I've been bashing my head against the wall for a while now trying to figure out wtf is going on

mib_kmvjos: which is not the case

shep: ah i see

so kinda needs a tmp value until the end of the block

so the ref is kept alive

mib_kmvjos: so you need two lifetimes there, let's call `'a` and `'b`, and you need to make sure that one outlives the other

at least for the lifetime checker

yep. So NLL would not help here, since the `Package` would be dropped

mib_kmvjos: so `<'a, 'b: 'a>` and `Cow<'a, Foo<'b>>`,

whats the purpose of Package btw?

Shayanjm: so what's happening is that that crate checks in the bindings, and the bindings were generated on Mac OS

Shayanjm: Mac OS has weird backend mangling which adds an undescore to the symbols

hmm interesting

what's the recourse for this?

Shayanjm: bindgen adds the `#[link_name]` attribute for that case because for C++ trying to figure out the right symbol is a pain. In this case it shouldn't be needed

I see cfg(feature = "gen") in the build.rs, so would I just need to run cargo build --features gen to course correct here?

ray: yeah....

It's the best way I could figure out how to make the borrowchecker work for me

Shayanjm: deleting the `#[link_name = "\u{1}_hs_alloc_scratch"]` lines should work. Looks like `--features gen` should make bindgen run at build time, so that should work too

Basically, the `Package` contains all sorts of unsafe chunks of memory to deal with the web of links that is a DOM

Sweet, let me try this

and when you get a `Document`, you aren't able to move those chunks of memory

(because of the reference)

emilio: if I have to decorate Foo with the additional lifetimes, then I won't be able to have this sort of recursive type structure, right?

emilio: so cargo build --features gen compiles correctly, but then if I cargo test it's the same issue with the undefined references

Shayanjm: you presumably need to `cargo test --features gen` too, right?

ah that would make sense lmao

one sec

okay awesome, so that works

to that point though, how would I pass --features gen to the crate when I'm compiling the larger project that implements it?

[dependencies] foo = { features = ["gen"], ... }

cargo build --release still throws the undefined errors if compiling from the parent project, presumably because bindgen isn't being run at compile for rust-hyperscan

Shayanjm: you need to add the `features = ["gen"]` to the Cargo.toml

awesome, thanks shep && emilio

haha, I just swooped in at the end, it's all emilio

running a full rebuild right now, it's looking good so far :)

hrm, there's no way to wrap a type that's not Send and make it Send, is there?

mib_kmvjos: that's true, but that's because that recursive structure doesn't make much sense, I think

I wish it were easier to add trait bounds depending on cfg(feature)

Noldorin: struct MyType(TypeThatIsNotSend); unsafe impl Send for MyType {} should work

Shayanjm: happy to help! :)

emilio, I don't really want to do this though. I just want to make a guarantee by wrapping it.

emilio: well I'm trying to put together a protobuf-like structure where there can be messages that have, as children, other messages that may or may not be borrowing their data

emilio: I think that fits with rust's single owner paradigm

mib_kmvjos: Right, but that means that all the borrowed values need to come from the same place, right, and thus have the same lifetime, right?

emilio: worked perfectly, can't thank you enough!

glandium: hmm that's another use case for trait aliases I suppose

also TIL about macOS's weird name mangling

that's a really good insight

durka42: yet another unimplemented rfc

I know :(

Noldorin: why does it need to be send? if you want to "send" non-Send data between threads there are things like Mutex for that

I implemented the parsing part but the trait code is just a huge mass of spaghetti

oh wait, Mutex doesn't work for making a non-Send thing Send

occultus, yep

Noldorin: what is the non-Send type?

occultus, and Rc

shep: thanks for the help, off to bed

emilio: I think so?

durka42: I'm somewhat happy trait aliases are not stabilized

trait Alias = Send + Sync + 'static; is strange to me... this isn't a trait, it is a bound

this conflates traits and bounds

emilio: wouldn't that mean I could just use one lifetime though? as I understand it, having a notation like Foo<'a> denotes that any references Foo contains live at least as long as 'a, not that their lifetimes are exactly 'a

mib_kmvjos: sure, but then what wouldn't compile is your method, and it makes sense because in the `Owned` case you're not handing out a reference that is guaranteed to live as long as the message, you're handing out an internal reference

mib_kmvjos: So something like that would need `&'message self` to compile, since that's the only thing that guarantees the compiler that it's going to last long enough: play.rust-lang.org/?gist=0296cf5a3f…5f40e45af1a8e704d48e&version=stable

mib_kmvjos: but of course that's probably not quite usable

mib_kmvjos: so you probably want something like this: play.rust-lang.org/?gist=42d96024a4…4527b08d171c8be21e1c&version=stable

emilio: right, but that second one's not useful if 'message is 'static then 'b has to also be 'static

emilio: and also that one doesn't make sense to me because it's returning references with lifetime 'b, which outlives lifetime 'message, but the values it's referencing may only live 'message, so wouldn't that potentially cause a dangling reference?

mib_kmvjos: err, yeah, you're right

so my question is now: why *does* Mutex<T> require T to be Send for the Mutex to be Send?

Noldorin: Because sending the mutex is like sending the T inside.

nox, give me an example of why this might be a problem

Noldorin: Mutex<Rc<T>>

i'm less sure if this fits into rust's model of what Send means, but operations on some data structures are only valid on the thread the data was originally created on

Noldorin: Did that help?

occultus: that's `Sync`

occultus: things that are Sync can be operated on via references from _other_ threads

emilio: thanks for the help, I'm gonna keep gnawing at this over the next week or so

occultus: i.e. if Thing is Sync, &Thing is Send

insaneinside: i'm not sure if that's the same as what i was referring to

insaneinside: i was thinking of foreign handle values like from Win32

nox, that's actually an example of what I don't see is bad

occultus, aren't e.g. `WinHnd`s just ints?

occultus: (or pointers?)

Noldorin: let foo = Rc::new("hello"); let mutex = Mutex::new(foo.clone()); send_mutex_to_other_thread_and_clone_the_Rc_there(mutex);

insaneinside: "just ints" that are not necessarily valid to use from another thread

exactly :)

Noldorin: It's bad in just the same way that doing it with Rc<T> is bad.

I think we're violently agreeing here ;)

insaneinside: so they are not-Send

Noldorin: "An example of a non-Send type is the reference-counting pointer rc::Rc. If two threads attempt to clone Rcs that point to the same reference-counted value, they might try to update the reference count at the same time, which is undefined behavior because Rc doesn't use atomic operations." doc.rust-lang.org/std/marker/trait.Send.html

nox, right...

makes sense

Noldorin: backtracking a bit, why do want/need to pretend that this non-Send type is Send?

nox, what about if any clones done on that new thread are dropped before the Mutex is unlocked. surely that would be safe?

occultus, for very pragmatic purposes, kind of boring here :P

it's just the type I'm given in a library. need to use it in a multi-threaded way

Why aren't you using Arc?

^^^^

Arc doesn't make non-Send into Send either

nothing does, and conceptually nothing probably should

occultus: I assumed their non-Send type was Rc<T> but that's a wild assumption indeed.

is there an accepted style for using comments to section my code?

Noldorin: The mutex being locked on that new thread is irrelevant, the other thread is what must not clone the Rc<T>.

ngc0202: None, but I sometimes put actual documentation on impl blocks.

You can put ## titles with Markdown there and whatnot.

nox, let's say that the Rc is only *ever* cloned (and then always dropped) within a lock.

I mean stuff like ///// ERROR STUFF /////

Noldorin: that can't be guaranteed

occultus, I can guarantee it quite easily from visual inspection of my code, however...

Noldorin: I don't see why the lock matters. Why do you need the Rc<T> if you control its entire lifetime?

huh?

I don't control the Rc<T>

it's embedded in a value I'm given

from another library

Noldorin: the only way to fix this is to change the library to make the type Send, assuming that it even can be

occultus, yeah... guess it just wasn't designed with that in mind

Noldorin: What's that type?

nox, TestServer in Gotham

ngc0202: I do `// ----------------------------------------------------------------` or `// ================================================================` or... you get the picture :)

Noldorin: TestServer is just a wrapper around an Rc

ngc0202: for extra fun, remove some of the separators and replace with labels

ok, do you use a standard number of dashes?

occultus, and a bunch more stuff...

but yes