[00:00:31] *** Joins: dinfuehr (dinfuehr@moz-1v6.2no.31.85.IP) [00:00:37] *** Joins: erickt (erickt@moz-qie.6p3.217.74.IP) [00:00:37] *** ChanServ sets mode: +ao erickt erickt [00:01:32] *** Quits: durka42 (durka42@moz-v6gf67.seas.upenn.edu) (Client exited) [00:01:43] *** Quits: ysgard (ysgard@moz-2f2.ndk.196.69.IP) (Quit: Leaving...) [00:01:49] *** AutomatedTester|AFK is now known as AutomatedTester [00:02:04] *** Quits: SneakySnake (snake@moz-i9is4u.pool.telekom.hu) (Quit: Leaving) [00:02:47] Anyone played with https://github.com/spicavigo/kafka-rust/ ? Trying to connect to an SSL protected Kafka instance I don't control [00:02:56] *** Quits: duncanlaird (chatzilla@moz-83kscv.mi.charter.com) (Ping timeout: 121 seconds) [00:03:10] *** Joins: mpark (mpark@moz-obt.j7d.161.12.IP) [00:03:32] *** NameNotFound is now known as zz_NameNotFound [00:03:46] *** Quits: asmyers (amyers@moz-osiar4.md.comcast.net) (Connection closed) [00:03:48] Is there a way to make rustc slightly less aggressive with method inlining, for profiling purposes? Most of my functions don't even show up in callgrind, I'm assuming that's because they are inlined [00:03:54] *** Quits: gopar (gopar@moz-5039uj.ca.comcast.net) (A TLS packet with unexpected length was received.) [00:03:57] *** Quits: ShadowIce (pyoro@moz-d6d775.hsi.kabel-badenwuerttemberg.de) (Quit: Leaving) [00:04:25] *** Joins: cpdean (cpdean@moz-5kt45q.res.rr.com) [00:04:34] *** Quits: dinfuehr (dinfuehr@moz-1v6.2no.31.85.IP) (Ping timeout: 121 seconds) [00:04:37] you can add #[inline(never)] [00:04:56] There's a `-C inline-threshold` option but I don't know how to use it [00:05:04] (You can probably find it in the Clang docs) [00:05:18] *** Joins: duncanlaird (chatzilla@moz-83kscv.mi.charter.com) [00:05:29] *** Quits: skade (skade@moz-l118s8.pools.vodafone-ip.de) (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) [00:05:53] @kmc: I have a lot of functions though, I'd rather not have to put that on all my functions [00:06:45] *** Quits: deuxLoop (jilou4@moz-kv6hc8.ma.comcast.net) (Ping timeout: 121 seconds) [00:07:14] mbrubeck: thanks I'm looking into it now [00:07:22] *** Quits: TheAnachron (TheAnachron@moz-7s6.t2a.13.91.IP) (Quit: WeeChat 1.4) [00:07:24] Morten: Apparently you can set `inline-threshold` lower than 225 to get less aggressive inlining than default, IIUC [00:08:07] mbrubeck: thanks! [00:08:13] *** Quits: jeffbradberry (jrb@moz-kpp3mi.biz.rr.com) (Ping timeout: 121 seconds) [00:08:29] *** Quits: cpdean (cpdean@moz-5kt45q.res.rr.com) (Ping timeout: 121 seconds) [00:08:45] *** Joins: jonmorehouse (jonmorehous@moz-l7c.sbr.3.216.IP) [00:08:46] *** Quits: fabiand (fabiand@moz-gjq82i.dip0.t-ipconnect.de) (Quit: Verlassend) [00:09:00] *** Joins: TheAnachron (TheAnachron@moz-7s6.t2a.13.91.IP) [00:09:00] *** Quits: jfo (jfo@moz-k3r.ebo.124.64.IP) (Connection closed) [00:09:09] *** Joins: benbergman (ben@moz-8vm.01g.81.208.IP) [00:09:22] *** Quits: duncanlaird (chatzilla@moz-83kscv.mi.charter.com) (Ping timeout: 121 seconds) [00:09:53] *** AutomatedTester is now known as AutomatedTester|AFK [00:10:22] *** AutomatedTester|AFK is now known as AutomatedTester [00:10:52] *** Quits: _Vi (vi@moz-bbs.vhj.131.104.IP) (Ping timeout: 121 seconds) [00:10:54] *** Quits: ashish10 (textual@moz-jl6.9o0.201.199.IP) (Connection closed) [00:10:54] I want to iterate over neighbouring pairs in a vector, ie. given vec![1, 2, 3, 4, 5] I want to have something like (1, 2), (2, 3), (3, 4), (4, 5) [00:11:16] benbergman: vec.iter().windows(2) [00:11:22] *** AutomatedTester is now known as AutomatedTester|AFK [00:11:32] benbergman: http://doc.rust-lang.org/std/primitive.slice.html#method.windows [00:11:34] *** Joins: duncanlaird (chatzilla@moz-83kscv.mi.charter.com) [00:11:37] ah, windows, I knew I had seen something in there before [00:11:38] thanks! [00:11:40] benbergman: Oh wait, it's vec.windows() [00:11:47] *** AutomatedTester|AFK is now known as AutomatedTester [00:11:51] (not vec.iter()) [00:12:42] *** Quits: kfpratt (kfpratt@moz-231605.ipv6.telus.net) (A TLS packet with unexpected length was received.) [00:12:49] *** Joins: amyers (amyers@moz-6nahl4.8iss.sd5s.0145.2601.IP) [00:13:04] *** Joins: kfpratt (kfpratt@moz-l1fdhq.ipv6.telus.net) [00:13:14] does panic call the destructors? [00:13:16] *** Joins: _Vi (vi@moz-bbs.vhj.131.104.IP) [00:13:19] darkstalker, yes. [00:13:33] *** Quits: amyers (amyers@moz-6nahl4.8iss.sd5s.0145.2601.IP) (Connection closed) [00:13:38] darkstalker, specifically, unwinding calls clean-up code, which calls destructors if appropriate. [00:13:43] *** Joins: amyers (amyers@moz-6nahl4.8iss.sd5s.0145.2601.IP) [00:14:43] *** Quits: mssbrg (mark@moz-duths4.compute.amazonaws.com) (Connection closed) [00:14:45] *** Parts: jamesr (sid10481@moz-et8ioc.ealing.irccloud.com) ("") [00:15:40] *** Quits: duncanlaird (chatzilla@moz-83kscv.mi.charter.com) (Ping timeout: 121 seconds) [00:17:05] *** Joins: taral (sid19346@moz-l90ulr.tooting.irccloud.com) [00:17:06] *** Quits: kfpratt (kfpratt@moz-l1fdhq.ipv6.telus.net) (Ping timeout: 121 seconds) [00:17:22] *** Quits: jkingyens (jkingyens@moz-qjbkeh.mtv2.mozilla.com) (Client exited) [00:17:34] Doing some FFI work... can someone help me verify I've done the lifetime dance appropriately? The goal is that a series of buffers are passed to `cat`, which must still be valid when `out` is called. http://is.gd/1VCHaQ [00:18:05] *** Joins: armistace (smuxi@moz-nn571h.optusnet.com.au) [00:18:18] *** Joins: duncanlaird (chatzilla@moz-83kscv.mi.charter.com) [00:19:31] *** Quits: mpark (mpark@moz-obt.j7d.161.12.IP) (Quit: My Mac has gone to sleep. ZZZzzz…) [00:20:06] *** Quits: scriptor (scriptor@moz-4k5i95.h6np.s8u9.2000.2604.IP) (Connection closed) [00:20:20] *** Quits: smorin (textual@moz-r2biq3.ca.comcast.net) (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) [00:20:27] *** Joins: scriptor (scriptor@moz-19q800.res.rr.com) [00:21:18] *** Joins: blackgoat (blackgoat@moz-stj.iu0.157.221.IP) [00:22:18] *** Joins: vmeson (rmacleod@moz-hs5cri.cable.teksavvy.com) [00:22:21] *** Quits: tadh (quassel@moz-frfl2r.biz.rr.com) (Connection closed) [00:22:24] *** Quits: duncanlaird (chatzilla@moz-83kscv.mi.charter.com) (Ping timeout: 121 seconds) [00:24:21] *** Quits: pczarn (piotr@moz-9un7t9.izacom.pl) (Quit: WeeChat 1.4) [00:24:29] *** Quits: scriptor (scriptor@moz-19q800.res.rr.com) (Ping timeout: 121 seconds) [00:24:45] *** Joins: duncanlaird (chatzilla@moz-83kscv.mi.charter.com) [00:26:10] *** Quits: Jayflux (Jayflux@moz-8j7bn1.dsl.as9105.com) (Quit: Leaving) [00:26:41] *** Joins: mpark (mpark@moz-obt.j7d.161.12.IP) [00:26:44] *** Joins: REMqb (REMqb@moz-ncl4qo.abo.wanadoo.fr) [00:26:46] *** Quits: spider-mario (spidermario@moz-coblcf.fbx.proxad.net) (A TLS packet with unexpected length was received.) [00:26:53] *** Joins: michaelgg (Mibbit@moz-c6r.kp9.216.201.IP) [00:27:00] *** Joins: durka42 (durka42@moz-sr9luh.wireless-pennnet.upenn.edu) [00:27:01] *** Quits: amyers (amyers@moz-6nahl4.8iss.sd5s.0145.2601.IP) (Ping timeout: 121 seconds) [00:27:21] *** Joins: kfpratt (kfpratt@moz-g6a.r2c.89.209.IP) [00:28:51] *** Quits: duncanlaird (chatzilla@moz-83kscv.mi.charter.com) (Ping timeout: 121 seconds) [00:29:12] *** Quits: armistace (smuxi@moz-nn571h.optusnet.com.au) (Ping timeout: 121 seconds) [00:29:18] *** Joins: dpc (dpc@moz-j55hov.ahkg.bqct.0647.2601.IP) [00:29:43] *** Parts: jatentaki (jatentaki@moz-jql1ld.dynamic.chello.pl) () [00:29:45] *** Joins: adu (ajr@moz-99ult9.md.comcast.net) [00:30:38] *** Joins: Kingsquee (kingsley@moz-3oducq.bchsia.telus.net) [00:31:18] *** Quits: munksgaard (munksgaard@moz-urnkl5.u.parknet.dk) (Ping timeout: 121 seconds) [00:31:26] *** Quits: lidavidm (lidavidm@moz-urs1vb.cit.cornell.edu) (Ping timeout: 121 seconds) [00:31:33] *** Joins: duncanlaird (chatzilla@moz-83kscv.mi.charter.com) [00:32:02] SpaceManiac: I don't see how it prevents those buffers to be destroyed before out is called [00:32:08] *** Quits: REMqb (REMqb@moz-ncl4qo.abo.wanadoo.fr) (Ping timeout: 121 seconds) [00:32:57] *** Quits: mmalone (mmalone@moz-adr.u03.49.209.IP) (Quit: My Mac has gone to sleep. ZZZzzz…) [00:33:32] badboy: the key seems to be `where 'buf: 'b2`, which does seem like it's asking for what SpaceManiac is after: ie, cat_move transforms container by progressively refining it's phantom lifetime. [00:33:45] *** Joins: fyolnish (fyolnish@moz-jqsevj.ucom.ne.jp) [00:33:48] * jmesmon is not experienced enough to say for sure that will do the right thing [00:34:02] *** Quits: eckhardt_ (eckhardt@moz-kv4te9.hq.squareup.com) (Connection closed) [00:34:35] *** Joins: eckhardt_ (eckhardt@moz-kv4te9.hq.squareup.com) [00:35:39] *** Quits: duncanlaird (chatzilla@moz-83kscv.mi.charter.com) (Ping timeout: 121 seconds) [00:35:44] *** Quits: Guest32 (textual@moz-ppkiif.ga.comcast.net) (Quit: Textual IRC Client: www.textualapp.com) [00:36:09] *** Quits: eckhardt_ (eckhardt@moz-kv4te9.hq.squareup.com) (Connection closed) [00:36:20] *** Joins: Darfeel (Thunderbird@moz-c4sq6v.pa.comcast.net) [00:36:25] *** Quits: brianloveswords (brianlovesw@moz-bvav7m.fios.verizon.net) (Quit: My Mac has gone to sleep. ZZZzzz…) [00:36:34] *** Joins: eckhardt_ (eckhardt@moz-kv4te9.hq.squareup.com) [00:36:38] *** Quits: eckhardt_ (eckhardt@moz-kv4te9.hq.squareup.com) (Connection closed) [00:36:45] ah, cat_move moves self [00:36:50] SpaceManiac: I don't know why you're parameterizing on 'buf. [00:36:58] *** Quits: chris_99 (chris_99@moz-g2jhk1.clients.your-server.de) (Quit: Leaving) [00:37:04] *** Joins: eckhardt_ (eckhardt@moz-kv4te9.hq.squareup.com) [00:37:06] If I were trying to convince myself, I'd probably attempt to write something with a similar internal requirements without unsafe{}, but I'm not sure that is even possible here, unless there is some container that has the exact semantics ( [00:37:10] You should assert that the passed-in buffers live as long as the Combiner itself. [00:37:17] and out should consume the Combiner. [00:37:39] I actually need `out` to be able to be called multiple times [00:37:43] I believe you can do this by just omitting the lifetime on the packets. [00:37:53] *** Joins: duncanlaird (chatzilla@moz-83kscv.mi.charter.com) [00:37:58] What happens when out is called multiple times? [00:38:42] there is a variant where you might call it with different parameters over several invocations [00:38:54] *** Joins: Ankhers (Ankhers@moz-f2pcsg.compute.amazonaws.com) [00:39:06] Why can't you use a new Combiner? [00:39:22] *** Quits: nicholasf2 (nicholasf@moz-fpp.9jk.136.1.IP) (Ping timeout: 121 seconds) [00:39:53] SpaceManiac: I'm not sure cat_move() should (publically) exist, but cat() should be fine [00:40:57] *** Joins: mmalone (mmalone@moz-adr.u03.49.209.IP) [00:41:07] *** Quits: Guest60563 (flo@moz-nq76bc.dclient.hispeed.ch) (Ping timeout: 121 seconds) [00:41:09] talchas: can we change the lifetime of self by reference? (if not, then that is why cat_move() exists) [00:41:09] yeah, cat_move isn't correct - it will make the lifetime shorter, which presumably is still unsafe [00:41:18] yeah, cat_move doesn't go. [00:41:18] *** Joins: jfo (jfo@moz-k3r.ebo.124.64.IP) [00:41:28] jmesmon: no, if you want to you need a move [00:41:31] jmesmon: why would you want to? [00:41:36] but that bound is unsafe [00:42:00] *** Quits: Manishearth (manishearth@moz-uc30rq.anapnea.net) (Ping timeout: 121 seconds) [00:42:00] *** Quits: duncanlaird (chatzilla@moz-83kscv.mi.charter.com) (Ping timeout: 121 seconds) [00:42:05] SpaceManiac: Oh, you mean you call cat() cat() cat() out() out() and the two outs work on the same buffers? Okay. [00:42:09] taral: I believe SpaceManiac is trying to work with an API that keeps references to data around until it frees them. [00:42:16] s/frees/releases/ [00:42:17] taral: yes, exactly [00:42:26] Yeah, so the buffers have to live as long as the combiner [00:42:40] *** bholley is now known as bholley_away [00:42:44] fn cat(&mut self, packet: &[u8]) [00:42:45] *** Joins: casey_ (casey@moz-v0ns05.tpgi.com.au) [00:42:56] no, the cat you have is correct [00:43:11] why do you have to parameterize on buffer lifetime? [00:43:12] without cat_move I believe everything there is correct [00:43:28] Lifetime subtyping should suffice. [00:43:43] taral: so, if I'm interpreting what the ffi call is doing, it'll basically be that cat() pushes a bunch of slices into a vec [00:43:57] and then out() reads from them in sequence [00:44:02] probably [00:44:24] so your cat function wouldn't ensure that packet is live for as long as out can be called [00:44:34] no? [00:44:35] it would just make sure that packet is live for the duration of cat [00:44:40] Hrm. [00:44:46] *** Joins: duncanlaird (chatzilla@moz-83kscv.mi.charter.com) [00:44:47] How do you do the equivalent of 'self? [00:44:48] *** Joins: decimate (decimate@moz-v6pcqt.dsl.bell.ca) [00:44:55] what is written right there [00:44:56] fn cat(&'self mut self, packet: &'self [u8]) [00:45:09] but you're not allowed to do that. [00:45:14] I mean, you could write that fn cat<'a>(&'a mut self, packet: &'a [u8]) [00:45:18] but that's not what you want [00:45:27] You're not allowed to put named lifetimes on self. [00:45:31] sure you can [00:45:35] Here's a version that keeps a Vec instead of using FFI, and has the same methods with the same signatures: http://is.gd/aVMqTu [00:45:37] Really? [00:45:41] I swear I ran into that before. [00:45:45] that says "borrow the input Combiner for as long as packet", which isn't what you want [00:45:45] *** Quits: nimajneb (roytenberg@moz-plckos.CWRU.Edu) (Client exited) [00:46:06] *** Quits: croyd (croyd@moz-nkq.284.10.129.IP) (Connection closed) [00:46:15] fn cat<'a, 'b: 'a>(&'a mut self, packet: &'b [u8])? [00:46:23] or maybe the other way around [00:46:25] you want "make sure the input Combiner lives as long as packet", which basically means "make sure the input Combiner could store a reference to packet", which is precisely what SpaceManiac has [00:46:26] *** Joins: REMqb (REMqb@moz-06l3bh.abo.wanadoo.fr) [00:46:28] subtyping makes my head hurt [00:46:44] You shouldn't need to parameterize Combiner on the buffer lifetimes [00:46:48] *** Quits: casey_ (casey@moz-v0ns05.tpgi.com.au) (Ping timeout: 121 seconds) [00:47:00] yes, you should [00:47:14] SpaceManiac: hmm, if that works then I was wrong when I said cat_priv was unsafe [00:47:15] *** Joins: smorin (textual@moz-r2biq3.ca.comcast.net) [00:47:16] A struct should be able to store pointers by default inside itself so long as the program guarantees that the pointers live at least as long as the struct. [00:47:50] and to do that, you parameterize on the lifetime, to mark that the struct contains a reference [00:48:00] That seems bizarre. [00:48:09] What happens if you don't? Error? [00:48:18] *** Joins: nicholasf (nicholasf@moz-61h.a98.47.203.IP) [00:48:19] At compile time [00:48:23] *** bholley_away is now known as bholley [00:48:27] *** Joins: cruor99 (cruor99@moz-0os33h.customer.cdi.no) [00:48:38] SpaceManiac: yeah, I mis-throught how the lifetimes work out there [00:48:39] Instead of runtime (or scarier still, lack of an error). [00:48:47] Oh, I see. You want to bind the struct to the region that bounds its references, so that the references can't be freed while the struct lives. [00:48:49] *** Quits: duncanlaird (chatzilla@moz-83kscv.mi.charter.com) (Ping timeout: 121 seconds) [00:48:58] *** Quits: tristans1 (tristanseif@moz-aqblut.res.rr.com) (Ping timeout: 121 seconds) [00:49:02] SpaceManiac: and thought that the cat_priv call only worked because it didn't have &'buf [u8] [00:49:47] *** Joins: tristans1 (tristanseif@moz-aqblut.res.rr.com) [00:50:03] SpaceManiac: ( http://is.gd/A0uXCi ) [00:50:59] it's too bad you need that shorter temp to help rust figure out the lifetime needed [00:51:10] *** Quits: mpark (mpark@moz-obt.j7d.161.12.IP) (Quit: My Mac has gone to sleep. ZZZzzz…) [00:51:12] Is there a way to generate a random number within a specific range? [00:51:35] *** Joins: duncanlaird (chatzilla@moz-83kscv.mi.charter.com) [00:51:37] *** Joins: tristanseifert (tristanseif@moz-aqblut.res.rr.com) [00:51:40] !crate rand [00:51:41] rand (0.3.14) - Random number generators and other randomness functionality. -> https://crates.io/crates/rand [00:51:59] LambdaComplex: https://doc.rust-lang.org/rand/rand/distributions/range/struct.Range.html [00:52:29] *** Quits: cruor99 (cruor99@moz-0os33h.customer.cdi.no) (Ping timeout: 121 seconds) [00:52:34] *** Joins: mpark (mpark@moz-obt.j7d.161.12.IP) [00:52:40] *** Joins: liquidmetal (liquidmetal@moz-u78kqf.fios.verizon.net) [00:52:58] *** Joins: nimajneb (roytenberg@moz-ej4dpv.CWRU.Edu) [00:53:27] *** Joins: mysteriouspants_ (cmiller@moz-l551r5.c3lg.prgv.0644.2601.IP) [00:53:42] *** Quits: mysteriouspants_ (cmiller@moz-l551r5.c3lg.prgv.0644.2601.IP) (Quit: Leaving) [00:53:51] *** Quits: tristans1 (tristanseif@moz-aqblut.res.rr.com) (Ping timeout: 121 seconds) [00:53:52] hi there. On associated types: Are they attractive mainly because Rust won't infer types in signatures? Are they strictly equivalent to using type parameters otherwise? I feel like I'm missing something. [00:54:40] Thanks for the help, all. Satisfied with the lifetimes now [00:54:42] michaelgg: did you check out the book chapter? it has a motivating example of why you'd use an associated type [00:54:52] michaelgg: the two things are like inputs (type parameters) and outputs (associated types) to a function [00:55:11] type parameters can be anything, e.g. you can implement `Foo for u16` as well as `Foo for u16` [00:55:24] Hi steve yes that's why I'm asking. The book explicitly calls out that it looks bad in the signature [00:55:29] but associated types can't be controlled independently to other parameters [00:55:37] *** Joins: urodna (urodna@moz-9vepd9.res.rr.com) [00:55:38] *** Joins: yw1 (yw@moz-li3.ldg.170.124.IP) [00:55:39] (i.e. they're "computed" from the main type parameters) [00:55:41] *** Quits: duncanlaird (chatzilla@moz-83kscv.mi.charter.com) (Ping timeout: 121 seconds) [00:55:48] yeah, it is much better for type inference [00:55:53] hmmm [00:55:57] and is possibly required for coherence somewhere [00:56:01] impl Foo for u8 { type T = i8; } and type Foo for u8 { type T = i16; } is illlegal [00:56:26] much like X -> Y can be /implemented/ by a set of (X, Y), there is a difference [00:56:27] (it's really the coherence (and related) things that's key here, type inference is a consequence of that.) [00:56:35] *** Quits: Andoriyu (Andoriyu@moz-uo1igi.biz.rr.com) (Ping timeout: 121 seconds) [00:56:38] So it's a restricted type parameter basically? [00:56:39] *** Joins: kerrang (kerrang@moz-8ka5mh.fios.verizon.net) [00:56:55] I guess you could think of it like that [00:57:09] I'm not sure how useful that line of thought is, though :) [00:57:09] *** Parts: kerrang (kerrang@moz-8ka5mh.fios.verizon.net) () [00:57:20] (as in, they behave fairly differently) [00:57:24] I believe they are roughly equivalent to haskell functional dependencies, which are written just like any othe type parameter [00:57:46] badboy: Is the range inclusive or exclusive? Or is it like X..Y where X is inclusive and Y is exclusive? [00:57:46] they're more like type families in type classes [00:57:58] (pretty much identical, in fact) [00:58:01] *** Joins: duncanlaird (chatzilla@moz-83kscv.mi.charter.com) [00:58:11] alright I'll read some more, thanks [00:58:15] huon: I don't actually know type families, but I'm pretty sure it winds up being entirely identical to functional dependencies too [00:58:27] *** Joins: croyd (croyd@moz-3bf3hs.cable.rcn.com) [00:58:35] (you can put bounds on them, yes? I honestly forget, it's been a while) [00:58:42] *** Quits: jviereck (Adium@moz-egksnd.dclient.hispeed.ch) (Quit: Leaving.) [00:58:43] LambdaComplex: the docu says: Types should attempt to sample in [low, high) [00:58:57] *** Joins: Donkey_ (Donkey@moz-o6b.q1g.4.149.IP) [00:59:07] LambdaComplex: so for primitive integers it will be including low, excluding high [00:59:11] *** Quits: eckhardt_ (eckhardt@moz-kv4te9.hq.squareup.com) (Connection closed) [00:59:13] distribution shouldn't be necessary. Just this should be good enough: thread_rng().gen_range(high, low) [00:59:42] oh, it has that? [00:59:46] Needs: extern crate rand; use rand::Rng; [01:00:20] ah, a convenience wrapper. LambdaComplex listen to pingveno [01:00:47] *** Quits: jonmorehouse (jonmorehous@moz-l7c.sbr.3.216.IP) (Ping timeout: 121 seconds) [01:01:08] *** Joins: peterjoel (peterjoel@moz-giu28j.range86-166.btcentralplus.com) [01:01:26] *** Joins: dinfuehr (dinfuehr@moz-1v6.2no.31.85.IP) [01:01:27] *** Quits: anty (anty@moz-ouh.5h9.234.187.IP) (Ping timeout: 121 seconds) [01:01:28] *** Joins: jonmorehouse (jonmorehous@moz-l7c.sbr.3.216.IP) [01:01:37] Am I right in thinking that there is no generic trait for trig functions? [01:02:00] *** Quits: mmalone (mmalone@moz-adr.u03.49.209.IP) (Quit: My Mac has gone to sleep. ZZZzzz…) [01:02:06] *** Quits: duncanlaird (chatzilla@moz-83kscv.mi.charter.com) (Ping timeout: 121 seconds) [01:02:17] *** Quits: areski (areski@moz-7o8r19.user.ono.com) (Ping timeout: 121 seconds) [01:02:19] *** Quits: foser_ (foser@moz-g0ha5f.dynamic.ziggo.nl) (Ping timeout: 121 seconds) [01:02:25] huon: yeah, it sounds like they are in fact the same feature type-theory wise, only with implementation differences [01:03:06] *** Quits: joy (Adium@moz-k60luo.2rkg.9kg1.0101.2620.IP) (Quit: Leaving.) [01:03:17] (and possibly functional dependencies are more general in ways that might be misleading) [01:03:27] peterjoel: in general, the standard library doesn't have many generic numeric things. i don't know about that specific one off the top of my head, but wouldn't surprise me. a lot of that stuff moved into the num crate [01:03:41] *** Quits: mpark (mpark@moz-obt.j7d.161.12.IP) (Quit: My Mac has gone to sleep. ZZZzzz…) [01:03:53] *** Quits: eddyb (eddyb@moz-1cs.31j.77.82.IP) (Ping timeout: 121 seconds) [01:04:00] *** Joins: micxjo (user@moz-psu8gk.fios.verizon.net) [01:04:04] *** Joins: ubsan_ (ubsan@moz-92sbjt.wa.comcast.net) [01:04:05] gotcha. I’ll take a look there [01:04:11] *** Joins: mmalone (mmalone@moz-adr.u03.49.209.IP) [01:04:21] *** Quits: jaen (jaen@moz-ifmik2.copit.pl) (Quit: WeeChat 1.4) [01:04:26] *** Joins: duncanlaird (chatzilla@moz-83kscv.mi.charter.com) [01:04:29] *** Quits: blackgoat (blackgoat@moz-stj.iu0.157.221.IP) (Quit: WeeChat 1.4) [01:05:11] *** Quits: firstdayonthejob (firstdayont@moz-bipmqq.cable.virginm.net) (Ping timeout: 121 seconds) [01:05:16] *** Joins: samx (sami@moz-oq8dni.dyn.optonline.net) [01:05:20] *** Quits: wldcordeiro (wldcordeiro@moz-806.5he.186.208.IP) (Ping timeout: 121 seconds) [01:05:29] *** Quits: dinfuehr (dinfuehr@moz-1v6.2no.31.85.IP) (Ping timeout: 121 seconds) [01:05:30] *** Joins: eckhardt_ (eckhardt@moz-kv4te9.hq.squareup.com) [01:05:39] we went through three or four major designs for numeric traits and were't happy with any of them, so we removed virtually all of it from the standard library [01:05:44] someday......... [01:06:15] steveklabnik: That would make a good article. Discussing the tradeoffs between the various designs. [01:06:26] I can easily create one for my own purposes [01:06:40] if num doesn’t have what I need [01:07:02] *** Quits: erickt (erickt@moz-qie.6p3.217.74.IP) (Ping timeout: 121 seconds) [01:07:22] (and it looks like it doesn’t) [01:07:24] Havvy: yeah, that'd be cool [01:08:31] *** Quits: duncanlaird (chatzilla@moz-83kscv.mi.charter.com) (Ping timeout: 121 seconds) [01:08:43] *** Quits: sogard (Mibbit@moz-bun.kgv.114.79.IP) (Quit: http://www.mibbit.com ajax IRC Client) [01:08:52] *** Quits: demilux (demilux@moz-153.u1a.99.70.IP) (A TLS packet with unexpected length was received.) [01:08:52] could I get a hand I'm not sure what I'm doing wrong here with my closure http://i.imgur.com/P1GiRDm.png [01:09:06] what font is that? [01:09:16] layl: wow, that's a pretty text editor [01:09:19] ^ [01:09:21] layl: This closure can be called more than once [01:09:28] layl: capture a 'state.clone()' instead [01:09:34] i would bet [01:09:35] *** Quits: orks (orks@moz-icj.3l1.84.93.IP) (Quit: rakede) [01:09:35] it's atom with Seti UI and Syntax, with liberation mono [01:09:42] layl: So you you want to pass `state` by value each time it's called, you'll need to clone or copy it each time [01:10:00] either by adding an explicit clone, or changing the type to be Copy [01:10:10] ah I see, that makes sense [01:10:11] I have got to set up Atom for Rust one of these days [01:10:26] I really hope I can find a way to simplify these APIs [01:10:31] i really liked atom for rust, but i'm too addicted to vim stuff, and the ex package wasn't quite enough yet [01:10:48] *** Joins: duncanlaird (chatzilla@moz-83kscv.mi.charter.com) [01:11:14] Still living in NP++ land... gave Atom a try once but got annoyed at it for something or another [01:11:25] 👍 for Atom + Rust [01:12:02] *** Joins: markstory (textual@moz-tb3ghu.cable.rogers.com) [01:12:53] *** Quits: oln (smuxi@moz-b97dhp.customer.cdi.no) (A TLS packet with unexpected length was received.) [01:13:08] *** Joins: mpark (mpark@moz-obt.j7d.161.12.IP) [01:13:17] *** Joins: Gyro (Gyro@moz-s88olm.gwi.net) [01:13:20] annoying bit in rust, having to clone your Rcs to a local renamed version if you want to use them in multiple closures [01:13:21] *** Quits: Gyro (Gyro@moz-s88olm.gwi.net) (Connection closed) [01:13:37] funny, I am already using Liberation Mono for my terminal, but wasn't using it for emacs [01:13:55] really good font [01:14:02] so in the Graph example it makes sense for N and E to be associated types because there'd never be two differing implementations for a given type? But like for Iterator, it means I can't have a struct that exposes two different types to iterate over? (Say, allowing iteration over u8s as well as bools?) [01:14:22] *** Joins: erickt (erickt@moz-qie.6p3.217.74.IP) [01:14:22] *** ChanServ sets mode: +ao erickt erickt [01:14:28] *** Quits: skeet70 (skeet70@moz-evm.d9f.15.71.IP) (Quit: My Mac has gone to sleep. ZZZzzz…) [01:14:41] should I plug clone_army! here? :) [01:14:53] *** Quits: duncanlaird (chatzilla@moz-83kscv.mi.charter.com) (Ping timeout: 121 seconds) [01:14:57] I guess it doesn't help for multiple closures really [01:15:03] overall this API has become so damn vocal http://i.imgur.com/emzj4zr.png [01:15:09] michaelgg: it does mean that [01:15:11] I wish there were more ways to simplify this [01:15:16] but usually the iterator itself is a separate adapter struct [01:15:28] so you could have an IntBool struct with .iter_ints() and .iter_bools() methods [01:15:28] *** Joins: Zorg (Zorg@moz-fknvkg.pa.comcast.net) [01:15:32] *** Quits: Nextra (Nextra@moz-q8jgs9.ewe-ip-backbone.de) (Quit: Leaving) [01:15:33] *** Quits: jdm (jdm@moz-mu9.06r.98.75.IP) (Quit: ) [01:15:46] it's just supposed to be a small helper for redirecting messages to the appropriate handlers [01:15:58] !crate closet [01:15:58] closet (0.1.3) - CLOSure-Enhancing Toolbox (CLOSET) provides some questionably-useful macro utilities for closures, including clone_army!, which reduces boilerplate for clone-capturing closures, and vindaloo!, which does automatic currying. -> https://crates.io/crates/closet [01:16:16] *** Quits: cpup (cpup@moz-lc8.jct.218.32.IP) (Ping timeout: 121 seconds) [01:16:24] ^ with this you can write clone_army!([state connection] dispatcher.register(...)) and just use "state" and "connection" in the closure [01:16:33] durka42: ok so associated types are when for a given type,trait pair, there's only one meaningful set of type parameters/associated types [01:16:38] durka42: thanks I'll take a look [01:16:47] yeah [01:16:50] *** Joins: cpup (cpup@moz-1im.ttd.218.32.IP) [01:16:55] *** zz_NameNotFound is now known as NameNotFound [01:17:30] associated types are meant to be, basically, returns [01:17:31] durka42: Heeeeh, that's porting C++ lambda syntax to Rust. [01:17:32] Me likes. [01:17:37] if you think of a trait as a function [01:17:38] kinda yeah [01:17:46] ok, apart from the inference stuff, what would break if associated types didnt exist? or would the type system just be poorer [01:17:48] *** Joins: duncanlaird (chatzilla@moz-83kscv.mi.charter.com) [01:17:55] *** Joins: brendan (brendaneich@moz-gkg7o7.ca.comcast.net) [01:18:07] I think it's mostly inference [01:18:12] michaelgg: Associated types are a fairly late addition to the language; most things are possible without them [01:18:31] however, inference does *suck* without them [01:18:47] like having to say something like let z: i32 = x + y; [01:18:51] Yeah, traits like Add weren't as flexible before, I think because of the inference problems [01:18:53] instead of let z = x + y; [01:19:08] *** AutomatedTester is now known as AutomatedTester|AFK [01:19:27] also, you can write functions/traits that use the associated types [01:19:41] like this addition function which is generic over its inputs and returns... whatever the addition returns [01:19:45] fn add>(a: T, b: U) -> U::Output { b + a } [01:19:52] *** bholley is now known as bholley_away [01:20:08] ubsan_ elaborate? if x and y are known then it'd only match one Add impl right? [01:20:12] (is this what a "projection" is?) [01:20:30] *** Quits: smorin (textual@moz-r2biq3.ca.comcast.net) (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) [01:20:40] durka42: fn add, Out>(a: T, b: U) -> Out { b + a } [01:20:59] durka42: is there an online documentation for this? [01:21:06] michaelgg: that doesn't mean that Rust can find that specific implementation [01:21:15] ubsan_: right, but same inference problem [01:21:30] durka42: quite [01:21:34] layl: try crates.fyi [01:21:47] *** Quits: erickt (erickt@moz-qie.6p3.217.74.IP) (Ping timeout: 121 seconds) [01:21:53] *** Quits: duncanlaird (chatzilla@moz-83kscv.mi.charter.com) (Ping timeout: 121 seconds) [01:21:59] layl: turns out I didn't write any docs though :( [01:22:03] *** ChanServ sets mode: +o jack [01:22:08] but this is how it works https://github.com/durka/closet/blob/master/tests/clone_army.rs#L32-L40 [01:22:30] it just takes a list of variables to clone and then an expression [01:22:37] got to run [01:22:43] is it possible to import a crate just for test functions? [01:22:49] durka42: o/ [01:23:00] peterjoel: [dev-dependencies] [01:23:00] but the inference problem here is partially that rust doesnt infer types for functions? [01:23:07] *** Quits: dmilith (dmilith@moz-8dkrre.interkar.pl) (Quit: Textual IRC Client: www.textualapp.com) [01:23:22] *** Joins: solidsnack (solidsnack@moz-kro69u.ca.comcast.net) [01:23:24] *** Quits: durka42 (durka42@moz-sr9luh.wireless-pennnet.upenn.edu) (Client exited) [01:23:34] @SpaceManiac, sorry I meant un-use-d [01:23:42] layl: blocks can let you reuse the var names and tuples do multi-cloning (https://gist.github.com/Nemo157/54f5e0a6611ac9c00820) [01:23:44] if it did then fn add (a,b) -> a + b should figure out the required traits and so on right? [01:23:50] layl: but, yeah... still not that nice [01:24:01] peterjoel: #[cfg(test)] use ...; ? [01:24:43] yes, works! Thanks [01:25:09] *** Quits: sheddow (sheddow@moz-2tmaov.3p.ntebredband.no) (Ping timeout: 121 seconds) [01:25:15] peterjoel: You can also use this pattern: http://doc.rust-lang.org/book/testing.html#the-tests-module [01:25:34] *** Parts: taral (sid19346@moz-l90ulr.tooting.irccloud.com) ("") [01:25:49] *** Quits: gleb (gleb@moz-3ir1e8.rusanovka-net.kiev.ua) (Ping timeout: 121 seconds) [01:25:50] *** Quits: FreeFull (freefull@moz-neaghq.skybroadband.com) (Ping timeout: 121 seconds) [01:26:16] *** Joins: dzbarsky (Adium@moz-39j6fl.82pc.j76f.0646.2601.IP) [01:26:34] *** Quits: brendan (brendaneich@moz-gkg7o7.ca.comcast.net) (Ping timeout: 121 seconds) [01:26:37] *** Joins: brendan (brendaneich@moz-990pl3.sub-70-214-7.myvzw.com) [01:26:43] *** Quits: rkruppe (chatzilla@moz-3nj.rnu.131.95.IP) (Ping timeout: 121 seconds) [01:27:47] *** Quits: housl (housl@moz-iqc.e3c.70.166.IP) (Quit: WeeChat 1.4) [01:28:09] *** NameNotFound is now known as zz_NameNotFound [01:28:21] *** zz_NameNotFound is now known as NameNotFound [01:28:52] @mbrubeck Thanks. I’m working on euclid, and just trying to fit around the patterns that are already there, without changing too much [01:28:59] *** Quits: Zorg (Zorg@moz-fknvkg.pa.comcast.net) (Quit: Textual IRC Client: www.textualapp.com) [01:29:29] *** Joins: Quxxy2 (Quxxy@moz-efh10q.internode.on.net) [01:29:57] michaelgg: the idea is that if Add didn't have an associated type, the return type would be a generic parameter; `impl Add for A` [01:29:58] peterjoel: Okay. We'd be happy to modernize euclid too (it's *really* old code), if you want to submit a separate commit for "move tests into a module" or whatever. Up to you. :) [01:30:08] heh, ok [01:30:15] I’ll create an issue at least [01:30:19] *** Quits: dzbarsky (Adium@moz-39j6fl.82pc.j76f.0646.2601.IP) (Ping timeout: 121 seconds) [01:30:19] *** Joins: duncanlaird (chatzilla@moz-83kscv.mi.charter.com) [01:30:22] Euclid dates to 2012, probably some of the oldest Rust code still in use :) [01:30:35] michaelgg: but that means i32 could impl `Add`, `Add`, `Add`, etc. [01:30:48] michaelgg: knowing A and B wouldn't be enough to be sure of the output type [01:31:09] I think it needs a spruce up in general [01:31:19] michaelgg: an associated type guarantees that there will only ever be one output type for a given pair of A and B [01:31:33] not sure if I like the method names - they don’t feel quite right [01:32:10] an probably `mul` can be replaced with implementing the Mul trait instead [01:32:10] *** Joins: dardevelin (dardevelin@moz-nsbqhh.rev.vodafone.pt) [01:32:17] yeah, definitely [01:32:20] and just use * [01:33:02] niconii: thanks [01:33:23] I”ll log the issue about tests, and at some point I’ll have a look over the naming and out of date stuff, and write up an issue for that too [01:33:39] (unless someone else gets there first) [01:34:27] *** Quits: duncanlaird (chatzilla@moz-83kscv.mi.charter.com) (Ping timeout: 121 seconds) [01:35:14] *** Quits: brendan (brendaneich@moz-990pl3.sub-70-214-7.myvzw.com) (Ping timeout: 121 seconds) [01:36:18] *** Joins: log0ymxm_ (log0ymxm@moz-lro.cl4.60.66.IP) [01:36:25] *** Joins: brendan (brendaneich@moz-990pl3.sub-70-214-7.myvzw.com) [01:37:22] *** Quits: jml (jml@moz-2uujnd.81.in-addr.arpa) (Ping timeout: 121 seconds) [01:37:24] *** Joins: duncanlaird (chatzilla@moz-83kscv.mi.charter.com) [01:37:57] *** Joins: Kilobyte (stephan@moz-958.qiu.232.93.IP) [01:38:31] *** Joins: Manishearth (manishearth@moz-uc30rq.anapnea.net) [01:38:31] *** ChanServ sets mode: +ao Manishearth Manishearth [01:38:32] can i do conditional compilation depending on if i am running in debug or release build? [01:38:50] *** Joins: wldcordeiro (wldcordeiro@moz-ul1rm9.ut.comcast.net) [01:38:54] *** Joins: jml (jml@moz-2uujnd.81.in-addr.arpa) [01:39:12] is in #[cfg(release)] [01:39:16] or sth like that [01:39:32] Kilobyte: the only cfg I know that's easily accessible is cfg(debug_assertions) [01:39:39] *** Quits: log0ymxm (log0ymxm@moz-lro.cl4.60.66.IP) (Ping timeout: 121 seconds) [01:40:06] *** Quits: TheAnachron (TheAnachron@moz-7s6.t2a.13.91.IP) (Quit: WeeChat 1.4) [01:40:20] *** Quits: log0ymxm_ (log0ymxm@moz-lro.cl4.60.66.IP) (Ping timeout: 121 seconds) [01:40:35] that looks promising, thanks [01:40:49] Yup, #[cfg(debug_assertions)] is the only one set automatically by rustc (for non-optimized builds) [01:41:10] You can also read $PROFILE in a Cargo build script [01:41:29] *** Quits: duncanlaird (chatzilla@moz-83kscv.mi.charter.com) (Ping timeout: 121 seconds) [01:41:31] a build script is the way to define your own cfg vars [01:42:59] If I mark something as #[deprecated], is there a way to signal the replacement API, or to write a custom warning message there? [01:43:19] *** Joins: casey_ (casey@moz-v0ns05.tpgi.com.au) [01:43:44] *** Joins: duncanlaird (chatzilla@moz-83kscv.mi.charter.com) [01:43:55] I can’t actually find documentation on #[deprecated], only an issue to added it, which is completed [01:44:04] peterjoel:sure, it's (note="message") [01:44:19] cool! [01:44:21] Thanks [01:44:27] *** Quits: Ketsuban (ketsuban@moz-hkhkkn.fpgk.pom1.0c7d.2a02.IP) (Quit: Leaving) [01:44:38] I hope it get stabilized soon [01:44:51] very useful stuff [01:45:07] well, yeah [01:45:10] *** Joins: ansible1 (kvirc@moz-ks4ued.co.comcast.net) [01:45:51] *** Joins: Andoriyu (Andoriyu@moz-a9o6ej.res.rr.com) [01:46:51] Another useful attribute might be: since=“version” [01:47:20] other question: can i specify cargo commands with special functionality from the Cargo.toml? (like cargo install) [01:47:22] *** Quits: casey_ (casey@moz-v0ns05.tpgi.com.au) (Ping timeout: 121 seconds) [01:47:33] or do i need to use a makefile for that [01:47:36] *** Quits: ferjm (textual@moz-nvpjsv.dynamicIP.rima-tde.net) (Quit: My Mac has gone to sleep. ZZZzzz…) [01:47:47] *** Quits: duncanlaird (chatzilla@moz-83kscv.mi.charter.com) (Ping timeout: 121 seconds) [01:48:10] Kilobyte: You need a makefile or some other outside-of-Cargo script, currently [01:48:31] too bad [01:48:43] Kilobyte: (You can write custom cargo commands, but they need to be built and installed separately; they can't be automatically loaded from the current directory) [01:48:58] i see [01:49:36] can i specify in my Cargo.toml to use a specific plugin or do i have to tell the user: use it [01:49:45] *** Joins: log0ymxm (log0ymxm@moz-34f99v.slkc.qwest.net) [01:49:46] in former case it wouldn't be that hard [01:50:40] *** Quits: brson (brson@moz-cfhap5.mtv2.mozilla.com) (Ping timeout: 121 seconds) [01:50:46] *** Joins: mindtree (Mitch@moz-r3o897.iprimus.net.au) [01:51:22] Just have to tell the user [01:51:38] ah okay [01:51:42] well, thanks [01:51:53] *** Joins: duncanlaird (chatzilla@moz-83kscv.mi.charter.com) [01:51:58] anyways, got a bit late so i'll be gone now [01:52:24] *** Quits: Kilobyte (stephan@moz-958.qiu.232.93.IP) (Quit: WeeChat 1.4) [01:53:09] *** Joins: brson (brson@moz-cfhap5.mtv2.mozilla.com) [01:53:10] *** ChanServ sets mode: +ao brson brson [01:53:48] *** Quits: log0ymxm (log0ymxm@moz-34f99v.slkc.qwest.net) (Ping timeout: 121 seconds) [01:54:30] *** Joins: sbw (Thunderbird@moz-gkj.r2e.173.59.IP) [01:54:56] *** Quits: mpark (mpark@moz-obt.j7d.161.12.IP) (Quit: My Mac has gone to sleep. ZZZzzz…) [01:55:09] *** Joins: mpark (mpark@moz-obt.j7d.161.12.IP) [01:55:43] *** Quits: jonmorehouse (jonmorehous@moz-l7c.sbr.3.216.IP) (Quit: WeeChat 1.3) [01:55:55] *** Joins: jonmorehouse (jonmorehous@moz-l7c.sbr.3.216.IP) [01:55:57] *** Quits: samx (sami@moz-oq8dni.dyn.optonline.net) (Quit: My Mac has gone to sleep. ZZZzzz…) [01:55:58] *** Quits: duncanlaird (chatzilla@moz-83kscv.mi.charter.com) (Ping timeout: 121 seconds) [01:56:12] *** Joins: demilux (demilux@moz-73qa6c.wa.comcast.net) [01:56:23] *** Quits: JanC (janc@moz-bkvart.dsl.scarlet.be) (Ping timeout: 121 seconds) [01:57:10] *** Quits: mpark (mpark@moz-obt.j7d.161.12.IP) (Quit: My Mac has gone to sleep. ZZZzzz…) [01:57:31] *** Joins: Stylez (Stylez@moz-6c2vrk.fios.verizon.net) [01:57:44] *** Quits: Tycheon (Tycheon@moz-71lipu.tycheon.ca) (Client exited) [01:58:14] *** Joins: duncanlaird (chatzilla@moz-83kscv.mi.charter.com) [01:58:56] *** Quits: mexisme (mexisme@moz-sdp.k7m.15.119.IP) (Client exited) [01:59:07] *** Joins: scriptor (scriptor@moz-3gclib.h6np.s8u9.2000.2604.IP) [01:59:27] *** Joins: mpark (mpark@moz-obt.j7d.161.12.IP) [01:59:28] *** Joins: erickt (erickt@moz-qie.6p3.217.74.IP) [01:59:28] *** ChanServ sets mode: +ao erickt erickt [01:59:33] *** Joins: Ketsuban (ketsuban@moz-jceb41.fpgk.pom1.0c7d.2a02.IP) [01:59:42] *** Joins: log0ymxm (log0ymxm@moz-34f99v.slkc.qwest.net) [02:00:44] *** Joins: galen (galen@moz-caprup.dsl-w.verizon.net) [02:00:45] *** Quits: mpark (mpark@moz-obt.j7d.161.12.IP) (Quit: My Mac has gone to sleep. ZZZzzz…) [02:02:19] *** Quits: duncanlaird (chatzilla@moz-83kscv.mi.charter.com) (Ping timeout: 121 seconds) [02:02:20] *** Joins: dinfuehr (dinfuehr@moz-1v6.2no.31.85.IP) [02:03:16] *** Quits: mindcat_ (mindcat@moz-9ss.7sq.30.14.IP) (Ping timeout: 121 seconds) [02:04:01] *** Joins: mexisme (mexisme@moz-sdp.k7m.15.119.IP) [02:04:27] *** Joins: samx (sami@moz-oq8dni.dyn.optonline.net) [02:04:32] *** Joins: duncanlaird (chatzilla@moz-83kscv.mi.charter.com) [02:04:47] *** Quits: REMqb (REMqb@moz-06l3bh.abo.wanadoo.fr) (Client exited) [02:05:13] *** Joins: cpdean (cpdean@moz-5kt45q.res.rr.com) [02:05:43] *** Quits: jonmorehouse (jonmorehous@moz-l7c.sbr.3.216.IP) (Quit: WeeChat 1.3) [02:05:47] *** Joins: jonmorehouse (jonmorehous@moz-l7c.sbr.3.216.IP) [02:06:05] *** Joins: ysgard (ysgard@moz-2f2.ndk.196.69.IP) [02:06:23] *** Quits: dinfuehr (dinfuehr@moz-1v6.2no.31.85.IP) (Ping timeout: 121 seconds) [02:07:13] *** Quits: dpc (dpc@moz-j55hov.ahkg.bqct.0647.2601.IP) (Ping timeout: 121 seconds) [02:08:37] *** Quits: duncanlaird (chatzilla@moz-83kscv.mi.charter.com) (Ping timeout: 121 seconds) [02:08:38] *** Quits: jonmorehouse (jonmorehous@moz-l7c.sbr.3.216.IP) (Quit: WeeChat 1.3) [02:09:14] *** Joins: shackra (shackrasisl@moz-afi.i2m.202.201.IP) [02:09:17] *** Quits: cpdean (cpdean@moz-5kt45q.res.rr.com) (Ping timeout: 121 seconds) [02:10:28] *** Joins: JanC (janc@moz-638amg.dsl.scarlet.be) [02:10:29] *** Joins: mindcat (mindcat@moz-c9u.7sq.30.14.IP) [02:10:40] *** Quits: mcarton (martin@moz-av5rpg.abo.wanadoo.fr) (Ping timeout: 121 seconds) [02:10:57] *** Joins: iceiceice (chris@moz-dgr.ac0.245.50.IP) [02:11:27] *** Joins: jonmorehouse (jonmorehous@moz-l7c.sbr.3.216.IP) [02:12:15] *** Quits: jonmorehouse (jonmorehous@moz-l7c.sbr.3.216.IP) (Quit: WeeChat 1.3) [02:12:18] *** Joins: duncanlaird (chatzilla@moz-83kscv.mi.charter.com) [02:13:20] *** Quits: shackra (shackrasisl@moz-afi.i2m.202.201.IP) (Ping timeout: 121 seconds) [02:14:52] *** Quits: rakm (rakm@moz-0hc.gir.115.17.IP) (Quit: My Mac has gone to sleep. ZZZzzz…) [02:15:47] *** Quits: espadrine (tyl@moz-9ga0p8.dd79.arl0.0e35.2a01.IP) (Ping timeout: 121 seconds) [02:16:13] *** Quits: lutter1 (lutter@moz-7v7ueu.PUBLIC.monkeybrains.net) (Ping timeout: 121 seconds) [02:16:25] *** Quits: duncanlaird (chatzilla@moz-83kscv.mi.charter.com) (Ping timeout: 121 seconds) [02:17:40] *** Quits: kfpratt (kfpratt@moz-g6a.r2c.89.209.IP) (A TLS packet with unexpected length was received.) [02:17:53] *** Joins: jonmorehouse (jonmorehous@moz-l7c.sbr.3.216.IP) [02:18:08] *** Joins: eckhardt2 (nodebot@moz-kv4te9.hq.squareup.com) [02:18:21] *** Quits: jonmorehouse (jonmorehous@moz-l7c.sbr.3.216.IP) (Quit: WeeChat 1.3) [02:18:34] *** Joins: duncanlaird (chatzilla@moz-83kscv.mi.charter.com) [02:18:48] *** Joins: jonmorehouse (jonmorehous@moz-l7c.sbr.3.216.IP) [02:19:01] *** Quits: markstory (textual@moz-tb3ghu.cable.rogers.com) (Quit: My Mac has gone to sleep. ZZZzzz…) [02:19:05] *** NameNotFound is now known as zz_NameNotFound [02:19:40] *** Quits: yw1 (yw@moz-li3.ldg.170.124.IP) (Ping timeout: 121 seconds) [02:21:16] *** Joins: smorin (textual@moz-r2biq3.ca.comcast.net) [02:21:36] *** Joins: jfredett (Adium@moz-qu294j.fios.verizon.net) [02:21:52] *** Quits: jonmorehouse (jonmorehous@moz-l7c.sbr.3.216.IP) (Quit: WeeChat 1.3) [02:22:15] *** zz_NameNotFound is now known as NameNotFound [02:22:29] *** Quits: samx (sami@moz-oq8dni.dyn.optonline.net) (Quit: My Mac has gone to sleep. ZZZzzz…) [02:22:38] *** Quits: duncanlaird (chatzilla@moz-83kscv.mi.charter.com) (Ping timeout: 121 seconds) [02:23:39] *** Joins: mcarton (martin@moz-7v1k36.abo.wanadoo.fr) [02:24:20] <_habnabit> src/arbitrary.rs:1104:28: 1104:38 error: unresolved import `super::Restricted`. There is no `Restricted` in `arbitrary`. Did you mean to use `Restricted`? [E0432] [02:24:23] <_habnabit> that's a fun message [02:24:34] *** Quits: vadix_ (vadix@moz-1fvvo7.hfc.comcastbusiness.net) (Ping timeout: 121 seconds) [02:24:50] *** Joins: duncanlaird (chatzilla@moz-83kscv.mi.charter.com) [02:25:38] *** Quits: jfredett (Adium@moz-qu294j.fios.verizon.net) (Ping timeout: 121 seconds) [02:25:40] <_habnabit> the module has `#[cfg(feature = "unstable")] mod unstable_impls { pub struct Restricted [...] } #[cfg(feature = "unstable")] use self::unstable_impls::Restricted;` in it [02:26:06] *** Joins: mindcat_ (mindcat@moz-g8d.7sq.30.14.IP) [02:26:15] <_habnabit> not sure if there's a better way to separate out unstable bits [02:26:37] *** Quits: Nemo157 (nemo157@moz-ag3.hnl.166.46.IP) (Ping timeout: 121 seconds) [02:26:49] *** Joins: markstory (textual@moz-tb3ghu.cable.rogers.com) [02:27:20] *** Joins: mpark (mpark@moz-obt.j7d.161.12.IP) [02:28:14] *** Quits: eckhardt2 (nodebot@moz-kv4te9.hq.squareup.com) (Quit: node-irc says goodbye) [02:28:25] *** bholley_away is now known as bholley [02:28:53] *** Quits: mindcat (mindcat@moz-c9u.7sq.30.14.IP) (Ping timeout: 121 seconds) [02:28:56] *** Quits: duncanlaird (chatzilla@moz-83kscv.mi.charter.com) (Ping timeout: 121 seconds) [02:28:59] *** bholley is now known as bholley_away [02:29:43] *** Quits: markstory (textual@moz-tb3ghu.cable.rogers.com) (Quit: My Mac has gone to sleep. ZZZzzz…) [02:29:50] *** Quits: mpark (mpark@moz-obt.j7d.161.12.IP) (Quit: My Mac has gone to sleep. ZZZzzz…) [02:30:09] *** bholley_away is now known as bholley [02:30:57] *** Joins: kfpratt (kfpratt@moz-52j7lo.abhsia.telus.net) [02:31:25] *** Quits: brendan (brendaneich@moz-990pl3.sub-70-214-7.myvzw.com) (Client exited) [02:31:37] *** Quits: mk (mk@moz-t0p.2l8.118.185.IP) (Ping timeout: 121 seconds) [02:31:46] *** NameNotFound is now known as zz_NameNotFound [02:32:17] *** Quits: futile (felix@moz-cursjl.unity-media.net) (Quit: WeeChat 1.4) [02:32:21] *** Quits: mindcat_ (mindcat@moz-g8d.7sq.30.14.IP) (Ping timeout: 121 seconds) [02:33:01] *** Quits: dardevelin (dardevelin@moz-nsbqhh.rev.vodafone.pt) (Ping timeout: 121 seconds) [02:33:45] *** Joins: mk (mk@moz-t0p.2l8.118.185.IP) [02:34:22] *** Joins: duncanlaird (chatzilla@moz-83kscv.mi.charter.com) [02:35:05] *** Joins: dardevelin (dardevelin@moz-nsbqhh.rev.vodafone.pt) [02:36:39] *** Quits: shadoi (shadoi@moz-24jpjh.ca.comcast.net) (Quit: Leaving.) [02:37:21] *** Quits: mmalone (mmalone@moz-adr.u03.49.209.IP) (Quit: My Mac has gone to sleep. ZZZzzz…) [02:37:22] *** Quits: erickt (erickt@moz-qie.6p3.217.74.IP) (Ping timeout: 121 seconds) [02:38:28] *** Quits: duncanlaird (chatzilla@moz-83kscv.mi.charter.com) (Ping timeout: 121 seconds) [02:39:13] *** Joins: indefini (indefini@moz-4p4v25.ucom.ne.jp) [02:39:41] *** Joins: erickt (erickt@moz-qie.6p3.217.74.IP) [02:39:41] *** ChanServ sets mode: +ao erickt erickt [02:39:53] *** Joins: mindcat (mindcat@moz-p5v.5o5.118.113.IP) [02:40:54] *** Quits: smorin (textual@moz-r2biq3.ca.comcast.net) (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) [02:41:20] *** Quits: tennix (vagrant@moz-k4r.hki.243.114.IP) (Ping timeout: 121 seconds) [02:42:36] *** Joins: mpark (mpark@moz-obt.j7d.161.12.IP) [02:43:43] *** Quits: erickt (erickt@moz-qie.6p3.217.74.IP) (Ping timeout: 121 seconds) [02:43:46] *** Joins: lutter1 (lutter@moz-7v7ueu.PUBLIC.monkeybrains.net) [02:44:04] *** Joins: casey_ (casey@moz-v0ns05.tpgi.com.au) [02:45:41] *** Quits: mcarton (martin@moz-7v1k36.abo.wanadoo.fr) (Ping timeout: 121 seconds) [02:46:07] *** Quits: nagisa (nagisa@moz-8t068g.static.zebra.lt) (Ping timeout: 121 seconds) [02:46:11] *** Joins: rakm (rakm@moz-v7p.c2c.114.17.IP) [02:46:52] *** Joins: narann (narann@moz-qjo.d4f.222.162.IP) [02:48:00] *** Joins: duncanlaird (chatzilla@moz-83kscv.mi.charter.com) [02:48:07] *** Quits: casey_ (casey@moz-v0ns05.tpgi.com.au) (Ping timeout: 121 seconds) [02:49:16] *** Joins: verynew (Mibbit@moz-une.jlv.72.24.IP) [02:49:35] *** Joins: cruor99 (cruor99@moz-0os33h.customer.cdi.no) [02:50:06] *** Joins: yw1 (yw@moz-li3.ldg.170.124.IP) [02:50:24] *** Quits: mexisme (mexisme@moz-sdp.k7m.15.119.IP) (Ping timeout: 121 seconds) [02:51:42] *** Quits: demilux (demilux@moz-73qa6c.wa.comcast.net) (A TLS packet with unexpected length was received.) [02:52:21] *** Quits: duncanlaird (chatzilla@moz-83kscv.mi.charter.com) (Ping timeout: 121 seconds) [02:52:24] *** Joins: mattrudder (textual@moz-l5tm8s.sntcca.sbcglobal.net) [02:53:13] *** Quits: Kingsquee (kingsley@moz-3oducq.bchsia.telus.net) (Connection closed) [02:53:37] *** Quits: cruor99 (cruor99@moz-0os33h.customer.cdi.no) (Ping timeout: 121 seconds) [02:53:59] *** Joins: mexisme (mexisme@moz-sdp.k7m.15.119.IP) [02:54:38] *** Joins: duncanlaird (chatzilla@moz-83kscv.mi.charter.com) [02:55:47] *** Joins: psd (uid62508@moz-6soqq9.richmond.irccloud.com) [02:56:26] *** Joins: xrash (smuxi@moz-e5misn.telesp.net.br) [02:57:19] *** Joins: jamesmacaulay (jamesmacaul@moz-s6ajs1.cable.rogers.com) [02:57:25] *** Quits: arBmind (Andreas@moz-4hm5ov.dyn.telefonica.de) (Connection closed) [02:57:49] *** Joins: acharles (acharles@moz-sq5a99.ca.comcast.net) [02:57:59] *** Quits: mitaa (mitaa@moz-4kctd0.dyn.drei.com) (Client exited) [02:57:59] *** Joins: erickt (erickt@moz-1ul.ggf.58.172.IP) [02:58:00] *** ChanServ sets mode: +ao erickt erickt [02:58:10] *** Quits: mattrudder (textual@moz-l5tm8s.sntcca.sbcglobal.net) (Quit: My Mac has gone to sleep. ZZZzzz…) [02:58:30] *** Joins: markstory (textual@moz-tb3ghu.cable.rogers.com) [02:58:35] *** Quits: scriptor (scriptor@moz-3gclib.h6np.s8u9.2000.2604.IP) (Connection closed) [02:58:43] *** Quits: duncanlaird (chatzilla@moz-83kscv.mi.charter.com) (Ping timeout: 121 seconds) [02:58:56] *** Joins: scriptor (scriptor@moz-19q800.res.rr.com) [02:59:01] *** Joins: arBmind (Andreas@moz-b51sut.adsl.alicedsl.de) [03:01:02] *** Quits: kfpratt (kfpratt@moz-52j7lo.abhsia.telus.net) (A TLS packet with unexpected length was received.) [03:01:12] *** Joins: kfpratt (kfpratt@moz-i9ehre.ipv6.telus.net) [03:01:12] *** Quits: jamesmacaulay (jamesmacaul@moz-s6ajs1.cable.rogers.com) (Connection closed) [03:01:23] *** Quits: mneumann (Thunderbird@moz-00qv32.rz.uni-karlsruhe.de) (Client exited) [03:01:26] *** Joins: duncanlaird (chatzilla@moz-83kscv.mi.charter.com) [03:01:36] *** Quits: fyolnish (fyolnish@moz-jqsevj.ucom.ne.jp) (Connection closed) [03:02:07] *** Joins: jonmorehouse (jonmorehous@moz-l7c.sbr.3.216.IP) [03:02:29] *** Joins: Kingsquee (kingsley@moz-3oducq.bchsia.telus.net) [03:02:56] *** Quits: fl3 (fl3@moz-ghm.6bs.172.109.IP) (Connection closed) [03:02:58] *** Quits: scriptor (scriptor@moz-19q800.res.rr.com) (Ping timeout: 121 seconds) [03:03:08] *** Joins: crisco__ (me@moz-u5efc8.dyn.telefonica.de) [03:03:15] *** Joins: dinfuehr (dinfuehr@moz-1v6.2no.31.85.IP) [03:03:21] *** Quits: peterjoel (peterjoel@moz-giu28j.range86-166.btcentralplus.com) (Client exited) [03:03:25] *** Quits: mpark (mpark@moz-obt.j7d.161.12.IP) (Quit: My Mac has gone to sleep. ZZZzzz…) [03:03:41] *** Joins: fyolnish (fyolnish@moz-jqsevj.ucom.ne.jp) [03:04:06] *** Quits: Pierre (Pierre@moz-u8e5in.slkc.qwest.net) (Ping timeout: 121 seconds) [03:04:36] *** Joins: mpark (mpark@moz-obt.j7d.161.12.IP) [03:05:29] *** Quits: duncanlaird (chatzilla@moz-83kscv.mi.charter.com) (Ping timeout: 121 seconds) [03:05:41] *** Joins: Makoryu (malleus@moz-0de80j.dyn.optonline.net) [03:05:41] *** Joins: jamesmacaulay (jamesmacaul@moz-s6ajs1.cable.rogers.com) [03:06:22] *** Joins: deuxLoop (jilou4@moz-kv6hc8.ma.comcast.net) [03:06:23] *** Quits: crisco_ (me@moz-rpnuaf.dyn.telefonica.de) (Ping timeout: 121 seconds) [03:06:26] *** Joins: mmalone (mmalone@moz-h55o2k.ca.comcast.net) [03:07:18] *** Quits: dinfuehr (dinfuehr@moz-1v6.2no.31.85.IP) (Ping timeout: 121 seconds) [03:07:41] *** Quits: Donkey_ (Donkey@moz-o6b.q1g.4.149.IP) (Connection closed) [03:07:49] *** Joins: duncanlaird (chatzilla@moz-83kscv.mi.charter.com) [03:07:58] *** Joins: dextertzu (dexter@moz-93n.534.55.96.IP) [03:08:02] *** Joins: Donkey_ (Donkey@moz-o6b.q1g.4.149.IP) [03:08:14] *** Quits: eckhardt_ (eckhardt@moz-kv4te9.hq.squareup.com) (Connection closed) [03:08:27] *** Joins: thpickert (thpickert@moz-v2i.ie6.61.108.IP) [03:09:46] *** Quits: thpickert (thpickert@moz-v2i.ie6.61.108.IP) (Client exited) [03:10:29] *** Quits: erickt (erickt@moz-1ul.ggf.58.172.IP) (Ping timeout: 121 seconds) [03:11:53] *** Quits: mpark (mpark@moz-obt.j7d.161.12.IP) (Quit: My Mac has gone to sleep. ZZZzzz…) [03:11:54] *** Quits: duncanlaird (chatzilla@moz-83kscv.mi.charter.com) (Ping timeout: 121 seconds) [03:12:02] *** Quits: nimajneb (roytenberg@moz-ej4dpv.CWRU.Edu) (Client exited) [03:12:04] *** Quits: Donkey_ (Donkey@moz-o6b.q1g.4.149.IP) (Ping timeout: 121 seconds) [03:12:17] *** Quits: jamesmacaulay (jamesmacaul@moz-s6ajs1.cable.rogers.com) (Ping timeout: 121 seconds) [03:12:30] *** Joins: futile (felix@moz-cursjl.unity-media.net) [03:13:31] *** Quits: Ketsuban (ketsuban@moz-jceb41.fpgk.pom1.0c7d.2a02.IP) (Quit: Leaving) [03:13:37] *** Quits: Fishrock123 (Fishrock123@moz-5igk34.dsl.bell.ca) (Connection closed) [03:13:52] *** Joins: eckhardt_ (eckhardt@moz-kv4te9.hq.squareup.com) [03:13:52] *** Joins: Donkey_ (Donkey@moz-o6b.q1g.4.149.IP) [03:13:53] *** Quits: goyox86 (textual@moz-rvv.00r.255.109.IP) (Quit: My Mac has gone to sleep. ZZZzzz…) [03:13:55] *** Joins: mcarton (martin@moz-m1bflr.abo.wanadoo.fr) [03:14:11] *** Joins: scriptor (scriptor@moz-34bc2c.h6np.s8u9.2000.2604.IP) [03:14:29] *** Joins: SiegeLord (sl@moz-s8hpnn.ca.comcast.net) [03:14:44] *** Joins: duncanlaird (chatzilla@moz-83kscv.mi.charter.com) [03:15:07] *** Joins: dpc (dpc@moz-j55hov.ahkg.bqct.0647.2601.IP) [03:16:19] *** Joins: tkellen (tkellen@moz-o7jjhb.vt.comcast.net) [03:16:54] *** Joins: sbeckeriv (becker@moz-cg0maa.tukw.qwest.net) [03:16:59] *** Quits: luke_nukem (ljones@moz-j9c.nac.54.210.IP) (Quit: Leaving) [03:18:45] *** Quits: duncanlaird (chatzilla@moz-83kscv.mi.charter.com) (Ping timeout: 121 seconds) [03:19:03] *** Joins: dfockler (dan@moz-rm6ima.wa.comcast.net) [03:19:05] *** Quits: solidsnack (solidsnack@moz-kro69u.ca.comcast.net) (Quit: My Mac has gone to sleep. ZZZzzz…) [03:19:11] *** Joins: demilux (demilux@moz-73qa6c.wa.comcast.net) [03:19:51] *** Quits: happy-dude_ (uid62780@moz-ljci7f.richmond.irccloud.com) (Quit: Connection closed for inactivity) [03:22:56] *** zz_NameNotFound is now known as NameNotFound [03:24:15] *** Joins: duncanlaird (chatzilla@moz-83kscv.mi.charter.com) [03:25:26] Anyone know what Byron on github’s irc nick is? [03:27:03] *** Joins: dzbarsky (Adium@moz-v18mcd.ca.comcast.net) [03:27:06] *** Joins: jechochamber (textual@moz-licqrv.ca.comcast.net) [03:28:01] *** Quits: nikkibee (quassel@moz-ja940m.ipv6.telus.net) (Quit: goodnight) [03:28:17] *** Quits: nhirata_ (nhirata_@moz-l8ebtf.sfo1.mozilla.com) (Client exited) [03:28:17] *** Joins: zrneely (zrneely@moz-ac6oq4.dyn.MIT.EDU) [03:28:19] *** Quits: duncanlaird (chatzilla@moz-83kscv.mi.charter.com) (Ping timeout: 121 seconds) [03:28:25] *** Joins: jamesmacaulay (jamesmacaul@moz-s6ajs1.cable.rogers.com) [03:28:36] *** Joins: FreeFull (freefull@moz-q7kqot.skybroadband.com) [03:29:19] *** Quits: zimbatm (quassel@moz-msgj2u.vhla.ggdv.19f0.2001.IP) (Quit: No Ping reply in 180 seconds.) [03:29:31] How do I reference struct using a variable? [03:29:47] *** Joins: ytain_ (ytain@moz-0j9n4p.cpe.pppoe.ca) [03:29:52] *** Quits: eckhardt_ (eckhardt@moz-kv4te9.hq.squareup.com) (Connection closed) [03:30:10] *** Joins: eckhardt_ (eckhardt@moz-kv4te9.hq.squareup.com) [03:30:22] Like, let var = "structname" and then reference a field with structname.fieldname [03:31:05] *** Quits: dzbarsky (Adium@moz-v18mcd.ca.comcast.net) (Ping timeout: 121 seconds) [03:31:21] *** Joins: zimbatm (quassel@moz-msgj2u.vhla.ggdv.19f0.2001.IP) [03:31:51] *** Joins: solidsnack (solidsnack@moz-kro69u.ca.comcast.net) [03:32:36] LambdaComplex: let x = &var.fieldname; ? [03:32:56] *** Quits: ytain (ytain@moz-5kl.l6u.10.76.IP) (Ping timeout: 121 seconds) [03:33:24] *** NameNotFound is now known as zz_NameNotFound [03:34:19] *** Joins: ytain (ytain@moz-eb854h.dsl.teksavvy.com) [03:34:40] *** Joins: lishuo (lishuo@moz-aka.rdt.57.119.IP) [03:34:51] *** Joins: yjv (uid110665@moz-99tp25.brockwell.irccloud.com) [03:35:18] can someone help explain to me whats going on here and what i did wrong? [03:35:19] http://is.gd/K7OpGE [03:35:19] *** Quits: pcwalton (pcwalton@moz-l8ebtf.sfo1.mozilla.com) (Client exited) [03:35:23] *** Quits: solidsnack (solidsnack@moz-kro69u.ca.comcast.net) (Quit: My Mac has gone to sleep. ZZZzzz…) [03:35:39] reem: Doesn't seem to be working [03:35:59] LambdaComplex: can you say more? what are you trying and what is the error? [03:36:48] *** Quits: steffengy (quassel@moz-lr0.v1j.180.87.IP) (Ping timeout: 121 seconds) [03:37:10] *** Joins: steffengy (quassel@moz-pkkjvs.dip0.t-ipconnect.de) [03:37:18] The Self::Line is a trait, which means it is not sizable? [03:37:32] *** Quits: ytain_ (ytain@moz-0j9n4p.cpe.pppoe.ca) (Ping timeout: 121 seconds) [03:37:37] yjv: The Self::Line is a trait, which means it is not sizable? [03:37:52] *** zz_NameNotFound is now known as NameNotFound [03:38:04] *** Joins: duncanlaird (chatzilla@moz-83kscv.mi.charter.com) [03:38:39] yjv: when you say fn x() { } T is chosen by the *caller* of x [03:38:46] and they can choose any T which meets the bounds [03:38:58] so your function says “for any iterator type, I can produce a value of that type” [03:39:09] *** Quits: jonmorehouse (jonmorehous@moz-l7c.sbr.3.216.IP) (Ping timeout: 121 seconds) [03:39:27] *** Joins: nimajneb (roytenberg@moz-ej4dpv.CWRU.Edu) [03:39:28] not “I produce some concrete iterator type of my choosing” [03:39:50] *** Joins: sunng (nsun@moz-6pt.rd3.117.123.IP) [03:41:26] *** Joins: erickt (erickt@moz-7h3.sdu.14.76.IP) [03:41:26] *** ChanServ sets mode: +ao erickt erickt [03:42:09] *** Quits: duncanlaird (chatzilla@moz-83kscv.mi.charter.com) (Ping timeout: 121 seconds) [03:43:13] *** Quits: Morten (Morten@moz-ltrurg.bb.online.no) (Quit: http://www.kiwiirc.com/ - A hand crafted IRC client) [03:44:25] *** Joins: tennix (vagrant@moz-p9e.mk0.204.111.IP) [03:44:37] *** Joins: mssbrg (mark@moz-duths4.compute.amazonaws.com) [03:44:50] *** Joins: casey_ (casey@moz-v0ns05.tpgi.com.au) [03:44:51] *** Quits: nimajneb (roytenberg@moz-ej4dpv.CWRU.Edu) (Client exited) [03:46:00] *** Quits: dextertzu (dexter@moz-93n.534.55.96.IP) (Ping timeout: 121 seconds) [03:46:25] *** Quits: jfo (jfo@moz-k3r.ebo.124.64.IP) (Connection closed) [03:46:49] *** Quits: tarrant (tarrant@moz-bah.kjq.104.38.IP) (Connection closed) [03:47:25] *** Quits: layl (layl@moz-65hqmf.direct-adsl.nl) (Quit: WeeChat 1.4) [03:47:27] *** Quits: isomarcte (isomarcte@moz-1hhheu.albq.qwest.net) (Ping timeout: 121 seconds) [03:47:41] *** Joins: zrsmith92 (textual@moz-3m7krt.dyn.suddenlink.net) [03:48:18] *** Joins: blanket (blank@moz-v0medr.mpls.qwest.net) [03:48:20] *** NameNotFound is now known as zz_NameNotFound [03:48:53] *** Quits: casey_ (casey@moz-v0ns05.tpgi.com.au) (Ping timeout: 121 seconds) [03:49:26] *** Quits: decimate (decimate@moz-v6pcqt.dsl.bell.ca) (Quit: leaving) [03:49:30] *** Quits: adhoc (adhoc@moz-579fgj.internode.on.net) (Ping timeout: 121 seconds) [03:49:40] *** Quits: Darfeel (Thunderbird@moz-c4sq6v.pa.comcast.net) (Ping timeout: 121 seconds) [03:49:43] reem: interestgin didnt think of ti tht way [03:49:52] lishuo yeah its a trait [03:50:08] *** Joins: lidavidm (lidavidm@moz-urs1vb.cit.cornell.edu) [03:50:22] reem so if i want to say that the impl of the file trait should return an iterator [03:50:34] but i want to leave open what kind of iterator they choose to return [03:50:44] that done with associated types? [03:50:51] or is there another way [03:50:54] *** Joins: cruor99 (cruor99@moz-0os33h.customer.cdi.no) [03:51:18] *** Joins: junqed (junqed@moz-j9m.kef.70.178.IP) [03:51:21] *** Joins: ytain_ (ytain@moz-dlheon.dsl.teksavvy.com) [03:51:34] *** Quits: panicbit (panicbit@moz-5pdkvo.dip0.t-ipconnect.de) (Ping timeout: 121 seconds) [03:51:52] *** Quits: blanked (blank@moz-v0medr.mpls.qwest.net) (Ping timeout: 121 seconds) [03:51:57] *** Joins: duncanlaird (chatzilla@moz-83kscv.mi.charter.com) [03:52:00] steveklabnik: you around? [03:53:29] *** Quits: SiegeLord (sl@moz-s8hpnn.ca.comcast.net) (Quit: It's a joke, it's all a joke.) [03:53:42] *** Quits: tennix (vagrant@moz-p9e.mk0.204.111.IP) (Ping timeout: 121 seconds) [03:54:31] *** Quits: ytain (ytain@moz-eb854h.dsl.teksavvy.com) (Ping timeout: 121 seconds) [03:54:56] *** Quits: cruor99 (cruor99@moz-0os33h.customer.cdi.no) (Ping timeout: 121 seconds) [03:54:58] *** Joins: panicbit (panicbit@moz-5pdkvo.dip0.t-ipconnect.de) [03:55:20] *** Quits: junqed (junqed@moz-j9m.kef.70.178.IP) (Ping timeout: 121 seconds) [03:55:34] *** Joins: smorin (textual@moz-ja6.v9g.17.12.IP) [03:55:50] *** Joins: SiegeLord (sl@moz-s8hpnn.ca.comcast.net) [03:56:01] *** Joins: cpdean (cpdean@moz-5kt45q.res.rr.com) [03:56:19] *** Quits: duncanlaird (chatzilla@moz-83kscv.mi.charter.com) (Ping timeout: 121 seconds) [03:58:01] is it possible to #[cfg(...)] *parts* of a function? [03:58:26] kamalmarhubi: you can use `if cfg!(...) { ... } else { ... }` [03:58:31] *** Joins: duncanlaird (chatzilla@moz-83kscv.mi.charter.com) [03:58:42] SpaceManiac: yeah I was about to say "not that" [03:58:55] What specifically are you trying to #[cfg()]? [03:59:04] There's a feature gate for that, isn't there [03:59:24] *** Quits: brson (brson@moz-cfhap5.mtv2.mozilla.com) (Quit: leaving) [03:59:32] *** Quits: smorin (textual@moz-ja6.v9g.17.12.IP) (Quit: Textual IRC Client: www.textualapp.com) [03:59:37] reem: associated type the way to go? [03:59:41] SpaceManiac: actually maybe that will work [03:59:52] *** Joins: sleetdrop (sleetdrop@moz-pmb.klk.142.219.IP) [04:00:08] yjv: probably [04:00:12] I'm trying to have a feature for an experimental command line flag and its processing [04:00:14] alright [04:00:30] which includes enum variants (cfg-able) and some other stuff [04:00:39] just seems like a bi of overkillfor jsut one method but [04:00:53] for some reason I thought something wouldn't type check if I used if cfg!() { } but I think it might be fine [04:00:59] is there a way to make a default for an associated type? [04:01:42] *** Quits: dfockler (dan@moz-rm6ima.wa.comcast.net) (Ping timeout: 121 seconds) [04:01:50] *** Joins: jfo (jfo@moz-k3r.ebo.124.64.IP) [04:01:53] kamalmarhubi: if it turns out it doesn't type check, and you can use nightly, this should work: http://is.gd/UwziXj [04:01:55] *** Joins: tennix (vagrant@moz-kjb.7qo.39.106.IP) [04:02:11] *** Quits: jfo (jfo@moz-k3r.ebo.124.64.IP) (Connection closed) [04:02:14] *** Joins: adhoc (adhoc@moz-579fgj.internode.on.net) [04:02:38] *** Quits: duncanlaird (chatzilla@moz-83kscv.mi.charter.com) (Ping timeout: 121 seconds) [04:02:44] yjv: unstable: https://github.com/rust-lang/rust/issues/29661 [04:02:54] nice :( [04:02:56] thanks [04:03:32] *** Joins: Guest5 (textual@moz-hnb58r.oc.cox.net) [04:03:33] SpaceManiac: yeah that's what I'd like, but I think in this case I might be ok [04:04:03] now if only I could figure out how to cfg out some args to a macro [04:04:08] *** Joins: jga (asdf@moz-c1s.irn.129.186.IP) [04:04:10] *** Joins: dinfuehr (dinfuehr@moz-1v6.2no.31.85.IP) [04:04:33] *** Quits: jamesmacaulay (jamesmacaul@moz-s6ajs1.cable.rogers.com) (Quit: My Mac has gone to sleep. ZZZzzz…) [04:04:34] I think I don't understand pointers in rust: http://is.gd/n1HuTl [04:04:43] *** Joins: jamesmacaulay (jamesmacaul@moz-s6ajs1.cable.rogers.com) [04:04:50] *** Quits: lishuo (lishuo@moz-aka.rdt.57.119.IP) (Connection closed) [04:04:51] shouldn't that move the Vec to the pointer? [04:05:17] *** Joins: duncanlaird (chatzilla@moz-83kscv.mi.charter.com) [04:05:22] or it's actually referencing the null pointer? [04:05:56] *** Joins: newbie (eibwen@moz-foett2.dip0.t-ipconnect.de) [04:05:57] jga: 'V' is a *mut Vec, and its value is 0. `*V = v` is trying to set the pointed-to location (null) to `v` [04:06:08] *** Quits: erickt (erickt@moz-7h3.sdu.14.76.IP) (Ping timeout: 121 seconds) [04:06:49] SpaceManiac: so what's the most reasonable way to init that pointer? [04:06:52] *** Quits: yw1 (yw@moz-li3.ldg.170.124.IP) (Quit: WeeChat 1.3) [04:07:16] jga: What do you want it to point to? With that current example, you would be pointing to the variable on teh stack. [04:07:40] *** Quits: fyolnish (fyolnish@moz-jqsevj.ucom.ne.jp) (Connection closed) [04:07:48] I would like to make that newly created Vec "static" [04:08:13] *** Quits: dinfuehr (dinfuehr@moz-1v6.2no.31.85.IP) (Ping timeout: 121 seconds) [04:08:30] basically have a global Vec [04:08:36] Are you trying to access it from another thread? [04:09:06] no, only from one thread [04:09:08] You'll at least need a Box, so the Vec struct is heap allocated. [04:09:11] *** Quits: Peng (mnordhoff@moz-36j428.tachibana.mnrd.us) (A TLS packet with unexpected length was received.) [04:09:20] *** Joins: Peng (mnordhoff@moz-dk0k0p.kanzaki.mnrd.us) [04:09:22] jga: you might want to check out lazy_static! [04:09:22] *** Quits: duncanlaird (chatzilla@moz-83kscv.mi.charter.com) (Ping timeout: 121 seconds) [04:09:22] I haven't worked with statics before, so I don't know how they work with regards to that though. [04:09:41] jga: however, the issue now is [04:09:48] you're dropping V [04:10:09] *V = v; means "drop *V, then move v into V" [04:10:16] *** Joins: zacstewart (zacstewart@moz-qi6qci.ga.comcast.net) [04:10:20] you want to use ptr::write [04:10:33] oh, I tried *V = v; mem::forget(v); but it said it was already moved [04:10:39] so I guess I can try forgetting first [04:10:48] wait, what am I saying [04:10:56] you're dereferencing a null pointer [04:11:02] *** Joins: erickt (erickt@moz-7h3.sdu.14.76.IP) [04:11:02] *** ChanServ sets mode: +ao erickt erickt [04:11:10] that's just not allowed ever [04:11:26] !crate lazy_static [04:11:26] lazy_static (0.1.15) - A macro for declaring lazily evaluated statics in Rust. -> https://crates.io/crates/lazy_static [04:11:29] use this ^ [04:12:17] jga: You might want to use lazy_static and Vec::append to add elements dynamically. [04:12:35] (If that's possible) [04:12:46] then you can do something like lazy_static!{static ref VECTOR: Vec = Vec::new();} [04:12:49] and it'll just work [04:13:51] *** Quits: brainpro1 (michael@moz-9vjtig.mo.charter.com) (Quit: WeeChat 1.4) [04:14:13] *** Joins: Fishrock123 (Fishrock123@moz-5igk34.dsl.bell.ca) [04:14:19] *** Quits: kfpratt (kfpratt@moz-i9ehre.ipv6.telus.net) (A TLS packet with unexpected length was received.) [04:14:24] *** Joins: yw (yw@moz-li3.ldg.170.124.IP) [04:14:41] *** Joins: gopar (gopar@moz-5039uj.ca.comcast.net) [04:14:47] *** Quits: Peng (mnordhoff@moz-dk0k0p.kanzaki.mnrd.us) (A TLS packet with unexpected length was received.) [04:14:59] SpaceManiac: any idea if there's a way to conditionally compile an arbitrary token tree? [04:15:02] *** Joins: duncanlaird (chatzilla@moz-83kscv.mi.charter.com) [04:15:10] I have no idea [04:15:19] I want to either include an arg to a macro or not [04:15:27] *** Quits: LambdaComplex (adam@moz-76u5ge.nc.charter.com) (Quit: WeeChat 1.4) [04:15:32] ubsan: do you know if it's actually using an atomic for each access? [04:15:38] *** Quits: jamesmacaulay (jamesmacaul@moz-s6ajs1.cable.rogers.com) (Ping timeout: 121 seconds) [04:15:39] The Deref implementation uses a hidden static variable that is guarded by a atomic check on each access. On stable Rust, the macro may need to allocate each static on the heap. [04:15:45] *** Joins: Peng (mnordhoff@moz-dk0k0p.kanzaki.mnrd.us) [04:15:50] that would be just to expensive for me [04:15:52] jga: yes, it uses an atomic for each access [04:16:08] *** Quits: M_D_K (M_D_K@moz-qouth3.ca) (Ping timeout: 121 seconds) [04:16:19] they shouldn't be that expensive [04:16:33] especially compared to Vec [04:16:39] what are you doing? [04:16:44] *** Joins: hiptobecubic (john@moz-gdk.apf.62.136.IP) [04:17:12] it's a list of constants that I initialize at the beggining of the program [04:17:18] *** Joins: fyolnish (fyolnish@moz-jqsevj.ucom.ne.jp) [04:17:27] it looks like transmutting from Box to *T works [04:17:54] jga: just use Box::into_raw [04:18:00] *** Quits: dmac_ (dmac@moz-ajq52c.ca.comcast.net) (Ping timeout: 121 seconds) [04:18:16] *** Quits: Peng (mnordhoff@moz-dk0k0p.kanzaki.mnrd.us) (A TLS packet with unexpected length was received.) [04:18:30] ubsan: cool [04:18:35] *** Parts: dpc (dpc@moz-j55hov.ahkg.bqct.0647.2601.IP) ("Leaving") [04:18:45] *** Quits: Fishrock123 (Fishrock123@moz-5igk34.dsl.bell.ca) (Ping timeout: 121 seconds) [04:18:48] *** Joins: zacstewa1t (zacstewart@moz-qi6qci.ga.comcast.net) [04:19:26] *** Quits: duncanlaird (chatzilla@moz-83kscv.mi.charter.com) (Ping timeout: 121 seconds) [04:19:34] *** Quits: zacstewart (zacstewart@moz-qi6qci.ga.comcast.net) (Quit: Leaving...) [04:20:04] *** Joins: M_D_K (M_D_K@moz-qouth3.ca) [04:20:06] *** Joins: Peng (mnordhoff@moz-dk0k0p.kanzaki.mnrd.us) [04:20:24] *** Quits: cpup (cpup@moz-1im.ttd.218.32.IP) (Ping timeout: 121 seconds) [04:21:00] ubsan: awesome, it works as expected, thanks! [04:21:02] *** Joins: jonmorehouse (jonmorehous@moz-2pa6qr.uljc.uk63.6000.2606.IP) [04:21:20] *** Quits: fyolnish (fyolnish@moz-jqsevj.ucom.ne.jp) (Ping timeout: 121 seconds) [04:21:31] ajeffrey: ping! [04:21:36] *** Joins: cpup (cpup@moz-v36.ktm.218.32.IP) [04:22:03] *** Joins: nimajneb (roytenberg@moz-ej4dpv.CWRU.Edu) [04:22:40] erickt: pong! [04:23:39] *** Joins: jamesmacaulay (jamesmacaul@moz-s6ajs1.cable.rogers.com) [04:24:33] *** Joins: sub_pop (link@moz-cvs6b6.ca.comcast.net) [04:24:42] *** Joins: lishuo (lishuo@moz-aka.rdt.57.119.IP) [04:24:49] *** Quits: lishuo (lishuo@moz-aka.rdt.57.119.IP) (Connection closed) [04:25:10] *** Joins: lishuo (lishuo@moz-aka.rdt.57.119.IP) [04:25:50] *** Quits: markstory (textual@moz-tb3ghu.cable.rogers.com) (Quit: My Mac has gone to sleep. ZZZzzz…) [04:25:54] *** Joins: fyolnish (fyolnish@moz-jqsevj.ucom.ne.jp) [04:26:08] *** Quits: M_D_K (M_D_K@moz-qouth3.ca) (Ping timeout: 121 seconds) [04:26:49] *** Joins: samx (sami@moz-oq8dni.dyn.optonline.net) [04:27:33] *** Quits: japaric (japaric@moz-923.is2.230.201.IP) (Quit: WeeChat 1.4) [04:27:35] *** Joins: M_D_K (M_D_K@moz-qouth3.ca) [04:27:42] *** Joins: japaric (japaric@moz-923.is2.230.201.IP) [04:28:01] *** Joins: Zorg (Zorg@moz-fknvkg.pa.comcast.net) [04:28:22] *** Joins: demilux_ (demilux@moz-1vbme0.t0gi.41v9.0380.2600.IP) [04:29:39] *** Quits: demilux (demilux@moz-73qa6c.wa.comcast.net) (Connection closed) [04:29:57] *** Quits: fyolnish (fyolnish@moz-jqsevj.ucom.ne.jp) (Ping timeout: 121 seconds) [04:29:59] *** Joins: demilux (demilux@moz-73qa6c.wa.comcast.net) [04:30:03] *** Quits: mhcerri (mhcerri@moz-hnf.m94.138.177.IP) (Connection closed) [04:30:21] *** Joins: tripped (trip@moz-i4845h.cable.mindspring.com) [04:30:39] *** Quits: eckhardt_ (eckhardt@moz-kv4te9.hq.squareup.com) (Connection closed) [04:30:45] *** Joins: mhcerri (mhcerri@moz-hnf.m94.138.177.IP) [04:31:22] *** Joins: tarrant (tarrant@moz-0j0u5t.ca.comcast.net) [04:32:22] *** Quits: verynew (Mibbit@moz-une.jlv.72.24.IP) (Quit: http://www.mibbit.com ajax IRC Client) [04:32:33] *** Quits: lidavidm (lidavidm@moz-urs1vb.cit.cornell.edu) (Ping timeout: 121 seconds) [04:32:47] *** Joins: fyolnish (fyolnish@moz-jqsevj.ucom.ne.jp) [04:33:10] *** Joins: Darfeel (Thunderbird@moz-c4sq6v.pa.comcast.net) [04:33:20] *** Quits: demilux_ (demilux@moz-1vbme0.t0gi.41v9.0380.2600.IP) (Ping timeout: 121 seconds) [04:34:25] *** Joins: TechnoCrunch (TechnoCrunc@moz-fi9.68j.56.122.IP) [04:35:13] *** Quits: futile (felix@moz-cursjl.unity-media.net) (Quit: WeeChat 1.4) [04:35:17] *** Joins: kazagistar (Adium@moz-rbsnpe.client.bresnan.net) [04:36:32] *** Joins: ambaxter (ambaxter@moz-epl41q.res.rr.com) [04:36:49] *** Quits: fyolnish (fyolnish@moz-jqsevj.ucom.ne.jp) (Ping timeout: 121 seconds) [04:37:21] What type information would I use to store a unit struct in something like a map? [04:37:44] ambaxter: What do you mean? [04:37:56] Unit structs (`struct StructName;` are a type on their own) [04:38:12] *** Quits: ubsan_ (ubsan@moz-92sbjt.wa.comcast.net) (Connection closed) [04:38:13] *** Quits: TechnoCrunch (TechnoCrunc@moz-fi9.68j.56.122.IP) (Connection closed) [04:38:18] *** Joins: TechnoCrunch (TechnoCrunc@moz-fi9.68j.56.122.IP) [04:38:25] Mutabah: I'd like to store a list of them that implement a trait [04:38:34] or would that need to be boxed [04:38:35] ? [04:39:03] *** Quits: jonmorehouse (jonmorehous@moz-2pa6qr.uljc.uk63.6000.2606.IP) (Ping timeout: 121 seconds) [04:39:18] *** Quits: Donkey_ (Donkey@moz-o6b.q1g.4.149.IP) (Connection closed) [04:39:38] *** Quits: lutter1 (lutter@moz-7v7ueu.PUBLIC.monkeybrains.net) (Ping timeout: 121 seconds) [04:39:45] *** Joins: fyolnish (fyolnish@moz-jqsevj.ucom.ne.jp) [04:40:05] Say, if I have a struct with a whole bunch of HashMap fields, for different values of V but the same K, and I want to call the same method on all of them, is there a more concise way to do that than copy and paste [04:40:06] *** Quits: narann (narann@moz-qjo.d4f.222.162.IP) (Quit: Leaving) [04:40:07] *** Quits: adu (ajr@moz-99ult9.md.comcast.net) (Client exited) [04:40:10] *** zz_NameNotFound is now known as NameNotFound [04:40:26] *** Quits: jechochamber (textual@moz-licqrv.ca.comcast.net) (Ping timeout: 121 seconds) [04:40:32] ambaxter: You'd need a &-ptr for that [04:40:33] *** Joins: jonmorehouse (jonmorehous@moz-89hgu6.uljc.uk63.6000.2606.IP) [04:40:39] *** bholley is now known as bholley_away [04:41:04] Mutabah: Thanks! [04:42:56] *** Quits: rakm (rakm@moz-v7p.c2c.114.17.IP) (Quit: My Mac has gone to sleep. ZZZzzz…) [04:43:03] *** Quits: Noldorin (noldorin@moz-l5a.oum.207.90.IP) (Quit: –) [04:43:47] *** Quits: fyolnish (fyolnish@moz-jqsevj.ucom.ne.jp) (Ping timeout: 121 seconds) [04:44:37] *** Quits: Diggsey (uid120933@moz-ob9ou8.brockwell.irccloud.com) (Quit: Connection closed for inactivity) [04:45:26] *** Quits: mexisme (mexisme@moz-sdp.k7m.15.119.IP) (Client exited) [04:45:30] *** Quits: TechnoCrunch (TechnoCrunc@moz-fi9.68j.56.122.IP) (Connection closed) [04:45:34] *** Joins: waffles (wafflespean@moz-01r.856.193.113.IP) [04:45:36] *** Joins: TechnoCrunch (TechnoCrunc@moz-fi9.68j.56.122.IP) [04:45:41] *** Quits: TechnoCrunch (TechnoCrunc@moz-fi9.68j.56.122.IP) (Quit: AndroIRC - Android IRC Client ( http://www.androirc.com )) [04:45:42] *** Joins: casey_ (casey@moz-v0ns05.tpgi.com.au) [04:46:12] *** Quits: nimajneb (roytenberg@moz-ej4dpv.CWRU.Edu) (Client exited) [04:46:34] *** Quits: jonmorehouse (jonmorehous@moz-89hgu6.uljc.uk63.6000.2606.IP) (Ping timeout: 121 seconds) [04:46:38] *** Joins: fyolnish (fyolnish@moz-jqsevj.ucom.ne.jp) [04:47:23] *** Joins: jdm (jdm@moz-sic4ua.cpe.pppoe.ca) [04:47:23] *** ChanServ sets mode: +o jdm [04:47:27] *** Joins: ytain (ytain@moz-n7u.5gn.91.23.IP) [04:48:02] *** Quits: fyolnish (fyolnish@moz-jqsevj.ucom.ne.jp) (Connection closed) [04:48:04] *** Joins: fyolnish (fyolnish@moz-jqsevj.ucom.ne.jp) [04:48:31] *** Quits: cruor99_ (cruor@moz-0os33h.customer.cdi.no) (Ping timeout: 121 seconds) [04:48:32] *** Quits: mmalone (mmalone@moz-h55o2k.ca.comcast.net) (Quit: My Mac has gone to sleep. ZZZzzz…) [04:48:34] *** Quits: ytain (ytain@moz-n7u.5gn.91.23.IP) (Quit: Textual IRC Client: www.textualapp.com) [04:49:45] *** Quits: casey_ (casey@moz-v0ns05.tpgi.com.au) (Ping timeout: 121 seconds) [04:49:58] *** Joins: mmalone (mmalone@moz-h55o2k.ca.comcast.net) [04:50:20] *** Quits: kimundi (kimundi@moz-hk6smr.ugip.vfc0.57bc.2002.IP) (Ping timeout: 121 seconds) [04:50:33] *** Quits: ytain_ (ytain@moz-dlheon.dsl.teksavvy.com) (Ping timeout: 121 seconds) [04:51:54] *** Quits: waffles (wafflespean@moz-01r.856.193.113.IP) (Ping timeout: 121 seconds) [04:52:49] *** NameNotFound is now known as zz_NameNotFound [04:53:18] *** Quits: kazagistar (Adium@moz-rbsnpe.client.bresnan.net) (Quit: Leaving.) [04:53:59] *** Joins: jonmorehouse (jonmorehous@moz-1mg8i4.uljc.uk63.6000.2606.IP) [04:53:59] *** Quits: Amaranth (travis@moz-rrrpsq.cpe.cableone.net) (Ping timeout: 121 seconds) [04:55:16] *** Joins: eckhardt_ (eckhardt@moz-kv4te9.hq.squareup.com) [04:55:21] *** Joins: kimundi (kimundi@moz-n64pok.7mkj.dahd.57bc.2002.IP) [04:55:41] *** Joins: gus (quassel@moz-kgm.3mq.9.119.IP) [04:56:21] *** Quits: czarfacevillain (itsme@moz-sjbaeo.lightwire.co.nz) (Quit: My Mac has gone to sleep. ZZZzzz…) [04:56:29] *** Quits: urcra (urcra@moz-9lk9gn.cpe.webspeed.dk) (Connection closed) [04:56:38] *** Joins: kazagistar (Adium@moz-rbsnpe.client.bresnan.net) [04:56:47] *** Quits: Rym (uid91135@moz-l7h36v.ealing.irccloud.com) (Quit: Connection closed for inactivity) [04:57:29] embarrassing question time: Why do we need "emplace" versions of our container APIs? Is the compiler not smart enough to turn "let foo = Foo::new(); myvec[x] = foo;" into an in-place construction? [04:58:27] ("placement new" or whatever the right title for this is) [04:59:11] *** Joins: Peng_ (mnordhoff@moz-4bde0h.compute-1.amazonaws.com) [04:59:17] *** Quits: eckhardt_ (eckhardt@moz-kv4te9.hq.squareup.com) (Ping timeout: 121 seconds) [04:59:19] *** Quits: psd (uid62508@moz-6soqq9.richmond.irccloud.com) (Quit: Connection closed for inactivity) [04:59:31] *** Joins: ubsan_ (ubsan@moz-92sbjt.wa.comcast.net) [04:59:40] *** Quits: kazagistar (Adium@moz-rbsnpe.client.bresnan.net) (Quit: Leaving.) [04:59:55] *** Joins: Amaranth (travis@moz-rrrpsq.cpe.cableone.net) [05:00:21] *** Joins: stephen (user@moz-to5njc.m7k5.54kg.0101.2620.IP) [05:00:24] *** Quits: Andoriyu (Andoriyu@moz-a9o6ej.res.rr.com) (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) [05:00:47] *** Quits: zrneely (zrneely@moz-ac6oq4.dyn.MIT.EDU) (Ping timeout: 121 seconds) [05:01:45] what's the meaning of this? http://is.gd/2xqas5 [05:02:02] *** Quits: mhcerri (mhcerri@moz-hnf.m94.138.177.IP) (Connection closed) [05:02:20] *** Joins: tycoon177_ (Odoyle_@moz-ib495f.client.mchsi.com) [05:02:28] gus: I could never find a good description of "emplacement", what does it actually do? [05:02:50] *** Joins: ahihi2 (ahihi@moz-0t1257.bb.dnainternet.fi) [05:02:51] *** Joins: czarfacevillain (itsme@moz-n3s.5ll.54.210.IP) [05:02:52] *** Quits: ahihi (ahihi@moz-0t1257.bb.dnainternet.fi) (Connection closed) [05:02:56] *** Quits: Darfeel (Thunderbird@moz-c4sq6v.pa.comcast.net) (Client exited) [05:02:59] *** Joins: mhcerri (mhcerri@moz-hnf.m94.138.177.IP) [05:03:04] *** Joins: nonsensickle_ (nonsensickl@moz-4v0.gkd.16.182.IP) [05:03:06] Skyler: Type aliases aren't perfect representations of the types they alias. You could write `use self::A as B;` also [05:03:27] gus: I have the same question, it would be much better if we didn't have to add new apis [05:03:33] *** Quits: ubsan_ (ubsan@moz-92sbjt.wa.comcast.net) (Ping timeout: 121 seconds) [05:03:34] keeper: I think "placement new" is the more usual description in Rust discussions. Basically the idea is that instead of using the default allocator, you use something else (usually a container) to allocate the memory for you, and then you construct into that. [05:04:04] *** Joins: mattrudder (textual@moz-ar6k2i.ca.astound.net) [05:04:10] SpaceManiac: interesting. rust-bindgen does `pub enum Enum__A` and then `pub type A = Enum__A` for some reason [05:04:13] I mean, only if push gets inlined and it has special knowledge about malloc [05:04:18] *** Quits: ziad (ziad@moz-8cn550.sntcca.sbcglobal.net) (Client exited) [05:04:25] gus: So in your example, it wouldn't allocated any space on the stack? [05:04:48] Foo would be written directly into the vector? [05:04:51] (and if you build without optimizations and Foo has a large array, you suddenly get a stack overflow) [05:05:05] *** Joins: dinfuehr (dinfuehr@moz-1v6.2no.31.85.IP) [05:05:13] *** Joins: kazagistar (Adium@moz-rbsnpe.client.bresnan.net) [05:05:17] *** Quits: tycoon177 (Odoyle_@moz-ib495f.client.mchsi.com) (Ping timeout: 121 seconds) [05:05:36] *** Quits: nonsensickle (nonsensickl@moz-4v0.gkd.16.182.IP) (Ping timeout: 121 seconds) [05:05:55] keeper: yes. (at least that's my understanding, and it seems consistent with the discussion I've read) [05:06:14] *** Quits: iceiceice (chris@moz-dgr.ac0.245.50.IP) (Quit: Leaving) [05:06:26] *** bholley_away is now known as bholley [05:08:54] *** Joins: nimajneb (roytenberg@moz-ej4dpv.CWRU.Edu) [05:09:08] *** Quits: dinfuehr (dinfuehr@moz-1v6.2no.31.85.IP) (Ping timeout: 121 seconds) [05:09:11] It just seems odd. I could understand other languages needing help to understand this, but in Rust we already have strong aliasing information so I'd naively expect the compiler to be able to do the right thing automatically. [05:10:45] even for exotic cases like constructing into thread-local storage arena - that should just come down to "construct foo locally; get a mutable reference; move/assign foo to *ref" [05:10:56] although perhaps that last fails on non-Copy types? [05:11:14] Would *vec.get_mut().unwarp() = Foo::new() do that? Or is that invalid? [05:11:26] yeah that. [05:11:38] *** Quits: nimajneb (roytenberg@moz-ej4dpv.CWRU.Edu) (Client exited) [05:11:46] *** Quits: mhcerri (mhcerri@moz-hnf.m94.138.177.IP) (Connection closed) [05:11:55] Though IIRC [] is IndexMut, which already returns an &mut. [05:12:05] anyway, I see you have the same question as I do ;-) [05:12:28] *** Joins: mhcerri (mhcerri@moz-hnf.m94.138.177.IP) [05:12:30] *** Quits: mattrudder (textual@moz-ar6k2i.ca.astound.net) (Quit: Textual IRC Client: www.textualapp.com) [05:12:32] *** Joins: mattrudder (textual@moz-ar6k2i.ca.astound.net) [05:12:33] You could try looking at IR on play.rust [05:14:36] *** Quits: }ls{ (uhelp@moz-edj.62g.206.93.IP) (Quit: User terminated by real life interrupt) [05:15:25] *** Joins: Fishrock123 (Fishrock123@moz-5igk34.dsl.bell.ca) [05:17:35] *** Joins: dmac (dmac@moz-2ig65r.ca.comcast.net) [05:20:09] gus: the issue is that that is fine [05:20:12] but this is for push [05:20:28] *** Quits: Fishrock123 (Fishrock123@moz-5igk34.dsl.bell.ca) (Ping timeout: 121 seconds) [05:20:30] which has a whole ton of code between Foo::new() and actually writing it [05:20:43] *** Joins: lucian (lucian@moz-7hsb6f.cable.virginm.net) [05:21:02] ah ok - so the compiler isn't able to see that that's still "simple" from a dataflow pov.. [05:21:27] *** Quits: Hime (Hime@moz-7dts43.fbx.proxad.net) (Quit: leaving) [05:21:38] *** Joins: markstory (textual@moz-tb3ghu.cable.rogers.com) [05:22:22] *** bholley is now known as bholley_away [05:22:44] *** Joins: Yurume (Yurume@moz-0t8.piq.68.115.IP) [05:23:05] *** Quits: croyd (croyd@moz-3bf3hs.cable.rcn.com) (Connection closed) [05:24:15] *** Joins: nimajneb (roytenberg@moz-plckos.CWRU.Edu) [05:24:45] *** Quits: lucian (lucian@moz-7hsb6f.cable.virginm.net) (Ping timeout: 121 seconds) [05:28:00] *** Joins: dzbarsky (Adium@moz-shbu4e.82pc.j76f.0646.2601.IP) [05:29:04] *** Quits: mmalone (mmalone@moz-h55o2k.ca.comcast.net) (Quit: My Mac has gone to sleep. ZZZzzz…) [05:29:36] *** Quits: mindtree (Mitch@moz-r3o897.iprimus.net.au) (Ping timeout: 121 seconds) [05:30:38] *** Joins: mindtree (Mitch@moz-1auvn6.iprimus.net.au) [05:32:02] *** Quits: dzbarsky (Adium@moz-shbu4e.82pc.j76f.0646.2601.IP) (Ping timeout: 121 seconds) [05:36:26] *** Quits: fyolnish (fyolnish@moz-jqsevj.ucom.ne.jp) (Connection closed) [05:36:39] *** Quits: lishuo (lishuo@moz-aka.rdt.57.119.IP) (Connection closed) [05:36:41] *** Joins: kfpratt (kfpratt@moz-52j7lo.abhsia.telus.net) [05:36:41] *** Joins: lutter1 (lutter@moz-7v7ueu.PUBLIC.monkeybrains.net) [05:37:12] *** Joins: waffles (wafflespean@moz-rgf.948.23.1.IP) [05:37:30] *** Quits: demilux (demilux@moz-73qa6c.wa.comcast.net) (A TLS packet with unexpected length was received.) [05:37:38] *** Joins: fyolnish (fyolnish@moz-jqsevj.ucom.ne.jp) [05:39:42] *** Joins: aravindavk (aravinda@moz-m6j.f0d.244.121.IP) [05:40:08] *** Joins: ajcrites (Mibbit@moz-3msedh.at.cox.net) [05:40:25] *** Quits: ambaxter (ambaxter@moz-epl41q.res.rr.com) (Connection closed) [05:40:29] *** Quits: Guest5 (textual@moz-hnb58r.oc.cox.net) (Quit: My Mac has gone to sleep. ZZZzzz…) [05:40:38] *** Joins: nebopolis (Mibbit@moz-btllu0.wi.charter.com) [05:40:58] *** Joins: Guest5 (textual@moz-hnb58r.oc.cox.net) [05:41:02] *** Joins: finga (finga@moz-pi4.0k6.151.88.IP) [05:41:13] *** Quits: Guest5 (textual@moz-hnb58r.oc.cox.net) (Quit: My Mac has gone to sleep. ZZZzzz…) [05:41:53] I'm trying to use hyper to create a post request to get some data from a website. It's a simple post request with a request body, and I have it working in curl but the analog I have in rust gives me back an error from the server that indicates there's probably something wrong with the post body [05:41:59] *** Joins: brson (brson@moz-46r.e0n.56.172.IP) [05:41:59] *** ChanServ sets mode: +ao brson brson [05:43:33] https://gist.github.com/ajcrites/be97e70fce5e92138f08 [05:44:22] the data should be the same; I just copied it back and forth [05:44:36] *** Joins: ziad (ziad@moz-s65gmp.ca.comcast.net) [05:44:55] *** Quits: jamesmacaulay (jamesmacaul@moz-s6ajs1.cable.rogers.com) (Quit: My Mac has gone to sleep. ZZZzzz…) [05:46:20] *** Joins: casey_ (casey@moz-v0ns05.tpgi.com.au) [05:46:37] *** Quits: KitRedgrave (quassel@moz-pp4.3sd.150.107.IP) (Quit: No Ping reply in 180 seconds.) [05:46:58] *** Joins: KitRedgrave (quassel@moz-pp4.3sd.150.107.IP) [05:47:20] *** Joins: Nilabhra (nilabhra@moz-m6r.4ml.64.45.IP) [05:50:23] *** Quits: casey_ (casey@moz-v0ns05.tpgi.com.au) (Ping timeout: 121 seconds) [05:52:07] *** Joins: tristans1 (tristanseif@moz-aqblut.res.rr.com) [05:52:23] *** Joins: cruor99 (cruor99@moz-0os33h.customer.cdi.no) [05:54:37] *** Quits: tristanseifert (tristanseif@moz-aqblut.res.rr.com) (Ping timeout: 121 seconds) [05:55:19] *** zz_NameNotFound is now known as NameNotFound [05:55:36] *** Quits: sleetdrop (sleetdrop@moz-pmb.klk.142.219.IP) (Ping timeout: 121 seconds) [05:56:25] *** Quits: cruor99 (cruor99@moz-0os33h.customer.cdi.no) (Ping timeout: 121 seconds) [05:56:57] *** Quits: xrash (smuxi@moz-e5misn.telesp.net.br) (Ping timeout: 121 seconds) [05:57:03] *** Joins: xrash (smuxi@moz-1ddof8.telesp.net.br) [05:57:05] *** Joins: KarolisK (karolis@moz-gvd.m2s.249.89.IP) [05:58:28] okay, figured out it needs the ContentType header set [05:58:33] *** Quits: ajcrites (Mibbit@moz-3msedh.at.cox.net) (Quit: http://www.mibbit.com ajax IRC Client) [05:59:00] *** Quits: blanket (blank@moz-v0medr.mpls.qwest.net) (Connection closed) [06:00:20] *** Quits: sbeckeriv (becker@moz-cg0maa.tukw.qwest.net) (Client exited) [06:00:26] *** Joins: TimNN (TimNN@moz-r8l.9ss.89.141.IP) [06:01:18] *** Joins: demilux (demilux@moz-73qa6c.wa.comcast.net) [06:03:44] *** Joins: forgottenone (forgottenon@moz-mkv.em1.40.176.IP) [06:04:47] *** NameNotFound is now known as zz_NameNotFound [06:06:01] *** Joins: dinfuehr (dinfuehr@moz-1v6.2no.31.85.IP) [06:07:26] *** Quits: nimajneb (roytenberg@moz-plckos.CWRU.Edu) (Client exited) [06:08:43] *** Joins: blackgoat (blackgoat@moz-rpd.br7.104.222.IP) [06:09:12] *** Quits: urodna (urodna@moz-9vepd9.res.rr.com) (Client exited) [06:09:21] *** Joins: nimajneb (roytenberg@moz-plckos.CWRU.Edu) [06:10:04] *** Quits: dinfuehr (dinfuehr@moz-1v6.2no.31.85.IP) (Ping timeout: 121 seconds) [06:13:39] *** Joins: jfredett (Adium@moz-qu294j.fios.verizon.net) [06:14:15] *** Joins: will_sm (will-medran@moz-09s.dbi.142.75.IP) [06:14:28] *** Quits: meh (meh@moz-tcc.f65.42.151.IP) (Ping timeout: 121 seconds) [06:14:43] *** Joins: arjun_ (arjun@moz-702.hmn.165.122.IP) [06:14:56] *** Joins: lnostdal_ (lnostdal@moz-nc66ho.dsl.telepac.pt) [06:16:01] *** Quits: nimajneb (roytenberg@moz-plckos.CWRU.Edu) (Client exited) [06:16:18] *** Quits: forgottenone (forgottenon@moz-mkv.em1.40.176.IP) (Quit: Konversation terminated!) [06:16:33] *** Joins: jonmoreh1 (jonmorehous@moz-i7q3gp.uljc.uk63.6000.2606.IP) [06:16:52] *** Quits: aravindavk (aravinda@moz-m6j.f0d.244.121.IP) (Ping timeout: 121 seconds) [06:16:55] *** Joins: Fishrock123 (Fishrock123@moz-5igk34.dsl.bell.ca) [06:16:59] *** Joins: aravindavk (aravinda@moz-m6j.f0d.244.121.IP) [06:18:21] *** Quits: lnostdal__ (lnostdal@moz-jkk11u.dsl.telepac.pt) (Ping timeout: 121 seconds) [06:18:33] *** Joins: laumann (thomas@moz-s86j9i.0.fullrate.ninja) [06:18:38] *** Quits: RegulationD (RegulationD@moz-jpg5s7.ga.charter.com) (Ping timeout: 121 seconds) [06:19:00] *** Quits: jonmorehouse (jonmorehous@moz-1mg8i4.uljc.uk63.6000.2606.IP) (Ping timeout: 121 seconds) [06:20:08] *** Joins: gunther (Mibbit@moz-fdp.jmi.165.122.IP) [06:20:31] *** Joins: Andoriyu (Andoriyu@moz-a9o6ej.res.rr.com) [06:21:02] hah, so I got my first real Rust program working today, but pretty convinced the internals are not as good as they could be - does anyone feel like pointing out where I could be doing better? :D https://github.com/yoshuawuyts/rust-swagger-to-md/ [06:21:27] *** Quits: Fishrock123 (Fishrock123@moz-5igk34.dsl.bell.ca) (Ping timeout: 121 seconds) [06:22:17] *** Joins: RegulationD (RegulationD@moz-jpg5s7.ga.charter.com) [06:22:38] I definitely didn't write a couple of loops where I could've (still getting a grip on ownership), but I surely must be using wrong abstractions in other places too hah [06:23:04] yw: first thing that comes to mind - the indent spacing convention for rust is 4 spaces, not 2 ;) [06:23:24] *** Quits: markstory (textual@moz-tb3ghu.cable.rogers.com) (Quit: My Mac has gone to sleep. ZZZzzz…) [06:23:42] mindtree: haha, yeah I don't do 4 spaces and 120 chars wide - no matter what Yehuda prescribes, it doesn't fit on my monitor [06:23:57] *** Joins: annodomini (lambda@moz-qgii5v.ma.comcast.net) [06:23:57] *** Quits: elementalest (elementales@moz-tl5gav.pchg.6fet.44b8.2001.IP) (Ping timeout: 121 seconds) [06:24:09] *** Joins: elementalest (elementales@moz-35c1ed.internode.on.net) [06:25:16] not just yehuda, but the rust style guide (wherever that is), though I think it's 100 chars, not 120 [06:26:20] 'tis 100 chars [06:27:11] I still find 4 spaces a bit weird with rust, especially with all the indentation you end up with. But I'm begrudging switching my codebase from 2 -> 4 so it's easier for others to contribute. [06:27:34] keeper: rustfmt may be useful for your endeavour. [06:27:36] haha, yeah it seriously doesn't fit on my screen - rocking 12" split with a reasonable font size; 80 chars is the limit and 4 spaces is restrictive [06:27:59] Yurume: rustfmt makes lots of decisions I'm not happy with, I need to come up with a good configuration. [06:28:03] *** Quits: cpdean (cpdean@moz-5kt45q.res.rr.com) (Ping timeout: 121 seconds) [06:28:07] *** Quits: Peng (mnordhoff@moz-dk0k0p.kanzaki.mnrd.us) (Quit: Brief Pengdom maintenance) [06:28:13] *** Joins: Peng (mnordhoff@moz-dk0k0p.kanzaki.mnrd.us) [06:28:55] *** Quits: bluss (bluss@moz-rip51k.cust.bredbandsbolaget.se) (Ping timeout: 121 seconds) [06:29:06] rustfmt looks like it has plenty of options. [06:29:14] *** Quits: aravindavk (aravinda@moz-m6j.f0d.244.121.IP) (Quit: Konversation terminated!) [06:29:19] *** Quits: laumann (thomas@moz-s86j9i.0.fullrate.ninja) (Ping timeout: 121 seconds) [06:29:22] *** Joins: aravindavk (aravinda@moz-m6j.f0d.244.121.IP) [06:29:38] yw: sure, just thought I'd mention it as it was the first thing that came to mind (contributors may find it offputting to work with code that doesn't follow the basic style conventions, however you may not even be planning on having contributors this so it might not even matter) [06:29:54] *** Joins: mmalone (mmalone@moz-h55o2k.ca.comcast.net) [06:30:33] *** Quits: gunther (Mibbit@moz-fdp.jmi.165.122.IP) (Quit: http://www.mibbit.com ajax IRC Client) [06:30:44] mindtree: haha, no worries! My question was to get feedback, and you gave it - real appreciated! :D [06:30:50] *** Joins: zrneely (zrneely@moz-ac6oq4.dyn.MIT.EDU) [06:31:35] *** Joins: dpc (dpc@moz-j55hov.ahkg.bqct.0647.2601.IP) [06:31:53] *** Quits: samx (sami@moz-oq8dni.dyn.optonline.net) (Quit: My Mac has gone to sleep. ZZZzzz…) [06:32:14] *** Quits: gingermusketeer (gingermuske@moz-qu4988.compute.amazonaws.com) (Connection closed) [06:32:15] *** Joins: gingermusketeer (gingermuske@moz-5rsc6d.compute.amazonaws.com) [06:32:28] mindtree, yw, as a general rule, as long the rules are clear and applied consistently, it's too big a deal. [06:32:51] it's *not* too big of a deal. [06:32:56] * aatch fails at typ [06:33:41] although people will generally get annoyed at x+y [06:33:52] and by "people will generally" [06:34:03] I mean "I will always" [06:34:07] aatch: yeah, the same can be applied to consistency across the ecosystem too ;) [06:34:20] mindtree, meh [06:34:35] if you don't plan on having people contribute, it's not too big a deal [06:34:46] treat all the packages as black boxes! (e.g. the Node way) :D [06:35:05] *** Joins: kzan (kzand@moz-oecg7b.res.rr.com) [06:35:17] yw: just pls put spaces around binops [06:35:22] *** Quits: nicholasf (nicholasf@moz-61h.a98.47.203.IP) (Ping timeout: 121 seconds) [06:35:25] ubsan: including code review heh [06:35:39] ubsan: "binops"? [06:35:49] yw, "binary operators" [06:35:54] x + y, x - y, x * y, x % y, etc. [06:36:01] yw, "binops" is easier to type. [06:36:07] Is there any way to join strings in macro_rules? [06:36:10] oooh, yeah if I didn't do that then that was a mistake [06:36:14] dpc: concat! [06:36:38] *** Quits: jonmoreh1 (jonmorehous@moz-i7q3gp.uljc.uk63.6000.2606.IP) (Quit: WeeChat 1.3) [06:36:41] I like bangs being the macro identifier [06:36:43] *** bholley_away is now known as bholley [06:36:49] is there like a good way of wrapping errors on the top level? [06:36:53] *** Joins: lishuo (lishuo@moz-aka.rdt.57.119.IP) [06:37:01] *** Quits: lishuo (lishuo@moz-aka.rdt.57.119.IP) (Connection closed) [06:37:02] it means it always seems exciting when talking about macros [06:37:08] I'm going to println! [06:37:14] that text [06:37:17] etc. [06:37:22] *** Joins: lishuo (lishuo@moz-aka.rdt.57.119.IP) [06:37:27] *** Joins: jonmorehouse (jonmorehous@moz-18rh0c.res.rr.com) [06:37:30] *** Quits: will_sm (will-medran@moz-09s.dbi.142.75.IP) (Quit: Leaving) [06:37:59] *** Quits: jonmorehouse (jonmorehous@moz-18rh0c.res.rr.com) (Quit: WeeChat 1.3) [06:38:30] *** Joins: jonmorehouse (jonmorehous@moz-i7q3gp.uljc.uk63.6000.2606.IP) [06:40:09] *** Quits: sub_pop (link@moz-cvs6b6.ca.comcast.net) (Client exited) [06:40:41] *** Joins: ambaxter (ambaxter@moz-epl41q.res.rr.com) [06:42:12] *** Quits: brson (brson@moz-46r.e0n.56.172.IP) (Connection closed) [06:42:56] *** Joins: stephanbuys (Adium@moz-p5kb8o.afrihost.co.za) [06:43:15] *** Quits: jonmorehouse (jonmorehous@moz-i7q3gp.uljc.uk63.6000.2606.IP) (Quit: WeeChat 1.3) [06:43:26] *** Quits: lishuo (lishuo@moz-aka.rdt.57.119.IP) (Ping timeout: 121 seconds) [06:44:20] *** Joins: jonmorehouse (jonmorehous@moz-i7q3gp.uljc.uk63.6000.2606.IP) [06:44:25] *** Joins: Donkey_ (Donkey@moz-egs006.dyn.optonline.net) [06:44:44] *** Quits: ambaxter (ambaxter@moz-epl41q.res.rr.com) (Ping timeout: 121 seconds) [06:45:08] ubsan, Thanks. [06:45:19] dpc: np [06:46:13] *** Joins: jimb (user@moz-6gkikn.or.comcast.net) [06:47:06] *** Joins: casey_ (casey@moz-v0ns05.tpgi.com.au) [06:47:31] ubsan, How can I concat! a "const"? [06:47:54] I have a common prefix that I'd like to concat!() in couple of places instead of repeating. [06:47:58] ah [06:48:12] like, const X: &'static str = "prefix"; [06:48:13] ? [06:48:20] you want to concat X? [06:48:22] It works concat!("bla", $args); and want concat!(X, $args); [06:48:32] Yes. [06:48:37] unfortunately you can't really do that [06:48:37] Or anything that will be DRY. [06:48:43] concat! only works on string literals [06:48:49] Could it be in macro? [06:48:52] you could define a macro which expands... [06:48:53] yeah [06:49:00] Works with me. Thanks. [06:49:09] yup :) [06:49:58] *** Quits: yw (yw@moz-li3.ldg.170.124.IP) (Ping timeout: 121 seconds) [06:50:51] *** Quits: mattrudder (textual@moz-ar6k2i.ca.astound.net) (Quit: My Mac has gone to sleep. ZZZzzz…) [06:51:08] *** Quits: casey_ (casey@moz-v0ns05.tpgi.com.au) (Ping timeout: 121 seconds) [06:51:17] *** Joins: solidsnack (solidsnack@moz-kro69u.ca.comcast.net) [06:52:28] *** Quits: waffles (wafflespean@moz-rgf.948.23.1.IP) (Ping timeout: 121 seconds) [06:53:26] *** Quits: orangeshark (erik@moz-pdc35c.44tj.56ot.0306.2602.IP) (Quit: Leaving) [06:53:54] *** Joins: sbw1 (Thunderbird@moz-gkj.r2e.173.59.IP) [06:54:21] *** Joins: ubsan_ (ubsan@moz-92sbjt.wa.comcast.net) [06:54:39] hello? [06:55:19] *** Quits: solidsnack (solidsnack@moz-kro69u.ca.comcast.net) (Ping timeout: 121 seconds) [06:55:21] *** Quits: sbw (Thunderbird@moz-gkj.r2e.173.59.IP) (Ping timeout: 121 seconds) [06:55:21] *** sbw1 is now known as sbw [06:56:00] *** Quits: fyolnish (fyolnish@moz-jqsevj.ucom.ne.jp) (Connection closed) [06:58:37] anyone familiar with web frameworks for rust, specifically hyper or even iron (which layers Rust i believe) [06:59:21] i see these libraries try and compile openssl, and im having some difficulty compiling openssl automatically via cargo, needing to compile through mingw [07:00:17] *** Joins: will_sm (will-medran@moz-09s.dbi.142.75.IP) [07:00:33] *** Joins: skade (skade@moz-jjth55.pools.vodafone-ip.de) [07:00:35] *** Quits: beat (beat@moz-ddkqql.cpe.netcabo.pt) (Connection closed) [07:00:50] s/rust/hyper [07:01:15] *** Quits: lutter1 (lutter@moz-7v7ueu.PUBLIC.monkeybrains.net) (Connection closed) [07:01:15] *** Joins: munksgaard (munksgaard@moz-urnkl5.u.parknet.dk) [07:01:16] *** Joins: lutter1 (lutter@moz-7v7ueu.PUBLIC.monkeybrains.net) [07:02:05] *** Quits: nchambers (nchambers@moz-oa18l1.duckdns.org) (A TLS packet with unexpected length was received.) [07:02:18] *** Quits: agile (mike@moz-m71dqt.rcsntx.sbcglobal.net) (Quit: Leaving) [07:02:24] *** Joins: agile (mike@moz-m71dqt.rcsntx.sbcglobal.net) [07:02:44] *** Quits: sbw (Thunderbird@moz-gkj.r2e.173.59.IP) (Ping timeout: 121 seconds) [07:03:31] *** Joins: solidsnack (solidsnack@moz-kro69u.ca.comcast.net) [07:03:33] *** Joins: sbw (Thunderbird@moz-gkj.r2e.173.59.IP) [07:03:57] *** Joins: beat (beat@moz-ddkqql.cpe.netcabo.pt) [07:04:30] halcyon: yes [07:05:18] *** Quits: lutter1 (lutter@moz-7v7ueu.PUBLIC.monkeybrains.net) (Ping timeout: 121 seconds) [07:05:18] halcyon: does this help https://github.com/sfackler/rust-openssl#windows? [07:05:21] halcyon: you can disable the ssl feature from hyper (see cargo 'features') [07:06:00] *** Joins: durka42 (durka42@moz-d15k7q.pa.comcast.net) [07:06:22] seanmonstar: i believe it still tries to compile it tho [07:06:25] *** zz_NameNotFound is now known as NameNotFound [07:06:36] *** Joins: dellavg (dellavg@moz-iva.9jl.232.95.IP) [07:06:43] reem: hiya, nice to speak with you btw, you've done some pretty interesting things [07:06:57] *** Joins: dinfuehr (dinfuehr@moz-1v6.2no.31.85.IP) [07:07:15] reem: yes, that is the approach i have been taking, building via MingGQ [07:07:17] *W [07:07:24] *** Quits: Zorg (Zorg@moz-fknvkg.pa.comcast.net) (Quit: My Mac has gone to sleep. ZZZzzz…) [07:07:42] halcyon: thanks :) [07:08:00] its a bit of a pain, but i suspect it makes more sense to compile the OpenSSL libs than try and write a Rust OpenSSL alternitive [07:08:20] *** Joins: fyolnish (fyolnish@moz-jqsevj.ucom.ne.jp) [07:08:22] reem: its fine, ill just resort to building through mingq [07:08:27] *mingw [07:08:35] yeah, as seanmonstar said you can also disable https and ssl by turning off the ssl feature in iron [07:08:41] *** NameNotFound is now known as zz_NameNotFound [07:09:24] *** Joins: Fishrock123 (Fishrock123@moz-5igk34.dsl.bell.ca) [07:09:26] reem: i think i tried that in the past, it still attempts to build with openssl (last time i tried anyway) [07:09:32] ill try again [07:10:04] *** Quits: jga (asdf@moz-c1s.irn.129.186.IP) (Ping timeout: 121 seconds) [07:10:19] If disabled in hyper, it wont depend on openssl. Something else might [07:10:25] *** Quits: GeneralAltoids (GeneralAlto@moz-5g5.tco.159.98.IP) (Quit: Leaving.) [07:10:48] seanmonstar: yeah, just trying that [07:11:00] *** Quits: dinfuehr (dinfuehr@moz-1v6.2no.31.85.IP) (Ping timeout: 121 seconds) [07:11:17] seanmonstar: looks good, thanks guys [07:11:21] reem: ^ [07:11:25] *** Quits: mmalone (mmalone@moz-h55o2k.ca.comcast.net) (Quit: My Mac has gone to sleep. ZZZzzz…) [07:12:22] *** Quits: fyolnish (fyolnish@moz-jqsevj.ucom.ne.jp) (Ping timeout: 121 seconds) [07:13:34] *** Joins: mmalone (mmalone@moz-h55o2k.ca.comcast.net) [07:14:49] *** Joins: Eisfreak7 (Eisfreak7@moz-0fg8sh.pools.vodafone-ip.de) [07:15:33] *** Quits: solidsnack (solidsnack@moz-kro69u.ca.comcast.net) (Quit: My Mac has gone to sleep. ZZZzzz…) [07:16:19] *** Joins: fyolnish (fyolnish@moz-jqsevj.ucom.ne.jp) [07:16:38] *** Quits: annodomini (lambda@moz-qgii5v.ma.comcast.net) (Client exited) [07:18:41] *** Quits: Fishrock123 (Fishrock123@moz-5igk34.dsl.bell.ca) (Quit: Leaving...) [07:19:01] *** Quits: blackgoat (blackgoat@moz-rpd.br7.104.222.IP) (Quit: WeeChat 1.4) [07:19:04] great [07:20:21] *** Quits: fyolnish (fyolnish@moz-jqsevj.ucom.ne.jp) (Ping timeout: 121 seconds) [07:20:53] reem: so, just looking at hyper, do you know of anywork being done to upgrade the request to a web socket connection? [07:20:53] *** Quits: Makoryu (malleus@moz-0de80j.dyn.optonline.net) (Quit: Fast travel activated) [07:22:20] *** Joins: tikue (tikue@moz-u6dt3k.ca.comcast.net) [07:22:33] *** Quits: nonsensickle_ (nonsensickl@moz-4v0.gkd.16.182.IP) (Quit: Leaving) [07:23:17] *** Joins: dmac_ (dmac@moz-2ig65r.ca.comcast.net) [07:27:55] *** Quits: hoverbear (hoverbear@moz-f8g.ca5.97.172.IP) (Ping timeout: 121 seconds) [07:28:46] *** Joins: dzbarsky (Adium@moz-v18mcd.ca.comcast.net) [07:29:20] *** Joins: hoverbear (hoverbear@moz-f8g.ca5.97.172.IP) [07:29:46] *** Quits: mtyson (quassel@moz-pee.825.187.66.IP) (A TLS packet with unexpected length was received.) [07:29:50] *** Joins: sa2ajj (quassel@moz-2tn8l3.dhcp.inet.fi) [07:31:10] *** Joins: sbeckeriv (becker@moz-cg0maa.tukw.qwest.net) [07:31:12] *** Joins: eddyb (eddyb@moz-1cs.31j.77.82.IP) [07:31:26] *** Joins: solidsnack (solidsnack@moz-kro69u.ca.comcast.net) [07:31:49] *** Joins: fyolnish (fyolnish@moz-jqsevj.ucom.ne.jp) [07:32:42] *** Quits: skade (skade@moz-jjth55.pools.vodafone-ip.de) (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) [07:32:52] *** Quits: dzbarsky (Adium@moz-v18mcd.ca.comcast.net) (Ping timeout: 121 seconds) [07:34:29] *** Quits: Zr40 (zr40@moz-92llkv.adsl.xs4all.nl) (Ping timeout: 121 seconds) [07:34:51] *** Joins: lishuo (lishuo@moz-aka.rdt.57.119.IP) [07:35:51] *** Quits: fyolnish (fyolnish@moz-jqsevj.ucom.ne.jp) (Ping timeout: 121 seconds) [07:37:13] erickt: hey :) on github, serde's Serializer methods seem to have been renamed from visit_* to serialize_*. But this isn't on crates.io yet? [07:37:36] *** Quits: ubsan_ (ubsan@moz-92sbjt.wa.comcast.net) (Connection closed) [07:37:46] *** Joins: fyolnish (fyolnish@moz-jqsevj.ucom.ne.jp) [07:37:51] *** Joins: ubsan_ (ubsan@moz-92sbjt.wa.comcast.net) [07:38:00] *** Joins: mib_8s80bq (Mibbit@moz-pcdtpu.res.rr.com) [07:38:14] *** Joins: skade (skade@moz-hsb16a.dip0.t-ipconnect.de) [07:38:50] hi [07:39:37] *** Quits: Donkey_ (Donkey@moz-egs006.dyn.optonline.net) (Connection closed) [07:40:23] *** Joins: mvyskocil (mvyskocil@moz-1fo.p0p.7.31.IP) [07:40:55] *** Quits: mib_8s80bq (Mibbit@moz-pcdtpu.res.rr.com) (Quit: http://www.mibbit.com ajax IRC Client) [07:41:38] *** Quits: demilux (demilux@moz-73qa6c.wa.comcast.net) (A TLS packet with unexpected length was received.) [07:41:48] *** Quits: fyolnish (fyolnish@moz-jqsevj.ucom.ne.jp) (Ping timeout: 121 seconds) [07:42:01] *** Joins: ambaxter (ambaxter@moz-epl41q.res.rr.com) [07:42:15] *** Joins: fabiand (fabiand@moz-omrh14.dip0.t-ipconnect.de) [07:42:49] halcyon: there is https://cyderize.github.io/rust-websocket/doc/websocket/, but it’s a standalone server [07:44:02] *** Quits: mindtree (Mitch@moz-1auvn6.iprimus.net.au) (Ping timeout: 121 seconds) [07:44:28] reem: would be nice to combine them [07:45:46] *** Quits: SiegeLord (sl@moz-s8hpnn.ca.comcast.net) (Quit: Leaving) [07:45:54] *** Joins: foser (foser@moz-vchu7j.dynamic.ziggo.nl) [07:45:58] *** foser is now known as foser_ [07:46:03] *** Quits: ambaxter (ambaxter@moz-epl41q.res.rr.com) (Ping timeout: 121 seconds) [07:47:06] *** Quits: tarrant (tarrant@moz-0j0u5t.ca.comcast.net) (Connection closed) [07:47:09] *** Joins: slomo (slomo@moz-p8m0g2.net) [07:47:10] *** Joins: nimajneb (roytenberg@moz-plckos.CWRU.Edu) [07:47:37] *** Quits: ansible1 (kvirc@moz-ks4ued.co.comcast.net) (Ping timeout: 121 seconds) [07:48:00] *** Joins: casey_ (casey@moz-v0ns05.tpgi.com.au) [07:48:04] *** Joins: SiegeLord (sl@moz-s8hpnn.ca.comcast.net) [07:48:19] *** Joins: waffles (wafflespean@moz-vkc5fu.genomels.com) [07:48:46] *** Joins: sleetdrop (sleetdrop@moz-pmb.klk.142.219.IP) [07:49:16] *** Quits: dmac_ (dmac@moz-2ig65r.ca.comcast.net) (Ping timeout: 121 seconds) [07:49:27] *** Joins: mindtree (Mitch@moz-1auvn6.iprimus.net.au) [07:49:59] halcyon: well, you can run them on different ports like https://github.com/cyderize/rust-websocket/blob/master/examples/hyper.rs [07:51:15] *** Quits: munksgaard (munksgaard@moz-urnkl5.u.parknet.dk) (Ping timeout: 121 seconds) [07:52:03] *** Quits: casey_ (casey@moz-v0ns05.tpgi.com.au) (Ping timeout: 121 seconds) [07:53:34] *** Quits: Peng_ (mnordhoff@moz-4bde0h.compute-1.amazonaws.com) (Quit: Peng timeout) [07:53:38] *** Joins: cruor99 (cruor99@moz-0os33h.customer.cdi.no) [07:53:52] *** Quits: skade (skade@moz-hsb16a.dip0.t-ipconnect.de) (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) [07:54:31] what's the compiler invocation these days to print out expanded macros? [07:55:22] *** Quits: jdm (jdm@moz-sic4ua.cpe.pppoe.ca) (Quit: ) [07:55:22] bstrie: --pretty still iirc [07:55:31] *** Quits: aravindavk (aravinda@moz-m6j.f0d.244.121.IP) (Ping timeout: 121 seconds) [07:55:44] *** Joins: eckhardt_ (eckhardt@moz-0b0.bm2.248.98.IP) [07:56:09] bstrie: `--pretty expanded` [07:56:47] weird, I thought we got rid of that :P thanks [07:57:08] *** Joins: Zr40 (zr40@moz-92llkv.adsl.xs4all.nl) [07:57:21] *** Joins: Pierre (Pierre@moz-u8e5in.slkc.qwest.net) [07:57:25] *** Quits: Eisfreak7 (Eisfreak7@moz-0fg8sh.pools.vodafone-ip.de) (Quit: WeeChat 1.4) [07:57:40] *** Quits: cruor99 (cruor99@moz-0os33h.customer.cdi.no) (Ping timeout: 121 seconds) [07:57:53] *** bholley is now known as bholley_away [07:58:40] *** Quits: solidsnack (solidsnack@moz-kro69u.ca.comcast.net) (Quit: My Mac has gone to sleep. ZZZzzz…) [07:58:40] *** Quits: eckhardt_ (eckhardt@moz-0b0.bm2.248.98.IP) (Connection closed) [08:00:07] *** Joins: eckhardt_ (eckhardt@moz-0b0.bm2.248.98.IP) [08:00:50] *** Quits: erickt (erickt@moz-7h3.sdu.14.76.IP) (Ping timeout: 121 seconds) [08:01:49] *** Joins: yw (yw@moz-li3.ldg.170.124.IP) [08:02:10] *** Joins: alonlevy (alon@moz-nbi.32h.154.31.IP) [08:02:45] *** Quits: hiptobecubic (john@moz-gdk.apf.62.136.IP) (Ping timeout: 121 seconds) [08:03:08] *** Quits: sbeckeriv (becker@moz-cg0maa.tukw.qwest.net) (Client exited) [08:03:59] *** Joins: aravindavk (aravinda@moz-m6j.f0d.244.121.IP) [08:04:07] *** Joins: fyolnish (fyolnish@moz-jqsevj.ucom.ne.jp) [08:04:27] *** Joins: jkonecny (jkonecny@moz-vs8vb1.redhat.com) [08:05:07] reem: its nice to have the option to run them on the same port for some things [08:05:22] *** Quits: tycoon177_ (Odoyle_@moz-ib495f.client.mchsi.com) (Connection closed) [08:05:27] *** Joins: romanlevin (romanlevin@moz-jhq.qet.40.164.IP) [08:05:39] *** Quits: waffles (wafflespean@moz-vkc5fu.genomels.com) (Ping timeout: 121 seconds) [08:06:18] reem: all web sockets start out as regular http requests, its nice to be able to defined a socket route on a existing application, there are a few efforts out there, i suspect its a bit non trivial to achieve in rust [08:06:38] *** Quits: nimajneb (roytenberg@moz-plckos.CWRU.Edu) (Client exited) [08:07:04] *** Joins: waffles (wafflespean@moz-fdp.jmi.165.122.IP) [08:07:51] *** Joins: dinfuehr (dinfuehr@moz-1v6.2no.31.85.IP) [08:08:10] *** Quits: fyolnish (fyolnish@moz-jqsevj.ucom.ne.jp) (Ping timeout: 121 seconds) [08:08:34] *** zz_NameNotFound is now known as NameNotFound [08:10:01] *** Quits: will_sm (will-medran@moz-09s.dbi.142.75.IP) (Connection closed) [08:11:54] *** Quits: dinfuehr (dinfuehr@moz-1v6.2no.31.85.IP) (Ping timeout: 121 seconds) [08:13:45] *** Joins: fyolnish (fyolnish@moz-jqsevj.ucom.ne.jp) [08:13:57] *** Joins: SneakySnake (snake@moz-i9is4u.pool.telekom.hu) [08:14:15] *** Joins: vmx (vmx@moz-hev71m.dip0.t-ipconnect.de) [08:15:05] *** Quits: zrsmith92 (textual@moz-3m7krt.dyn.suddenlink.net) (Quit: My Mac has gone to sleep. ZZZzzz…) [08:17:22] *** Quits: fyolnish (fyolnish@moz-jqsevj.ucom.ne.jp) (Connection closed) [08:17:23] *** Joins: fyolnish (fyolnish@moz-jqsevj.ucom.ne.jp) [08:18:08] *** Quits: retropikzel (retropikzel@moz-8pe5l2.elisa-mobile.fi) (Quit: Leaving) [08:18:10] *** NameNotFound is now known as zz_NameNotFound [08:18:26] *** Joins: retropikzel (retropikzel@moz-8pe5l2.elisa-mobile.fi) [08:19:28] *** Quits: waffles (wafflespean@moz-fdp.jmi.165.122.IP) (Ping timeout: 121 seconds) [08:20:16] *** Quits: kazagistar (Adium@moz-rbsnpe.client.bresnan.net) (Quit: Leaving.) [08:21:03] *** Joins: skade (skade@moz-0djl38.boh1-r2.syseleven.net) [08:21:36] *** Quits: mmalone (mmalone@moz-h55o2k.ca.comcast.net) (Quit: My Mac has gone to sleep. ZZZzzz…) [08:23:02] *** Joins: djcb (user@moz-ptk.tnt.157.194.IP) [08:23:34] *** Quits: Cifram (Cifram@moz-l63.9pu.126.76.IP) (Connection closed) [08:23:42] *** Joins: Cifram (Cifram@moz-l63.9pu.126.76.IP) [08:24:05] *** Quits: zrneely (zrneely@moz-ac6oq4.dyn.MIT.EDU) (Ping timeout: 121 seconds) [08:25:44] *** Quits: durka42 (durka42@moz-d15k7q.pa.comcast.net) (Client exited) [08:26:25] *** Quits: TimNN (TimNN@moz-r8l.9ss.89.141.IP) (Quit: My Mac has gone to sleep. ZZZzzz…) [08:28:29] *** Quits: scriptor (scriptor@moz-34bc2c.h6np.s8u9.2000.2604.IP) (Connection closed) [08:28:50] *** Joins: scriptor (scriptor@moz-19q800.res.rr.com) [08:29:29] *** Quits: niconii (nicole@moz-af82ih.frgo.qwest.net) (Quit: leaving) [08:32:25] *** Quits: SiegeLord (sl@moz-s8hpnn.ca.comcast.net) (Quit: It's a joke, it's all a joke.) [08:32:52] *** Quits: scriptor (scriptor@moz-19q800.res.rr.com) (Ping timeout: 121 seconds) [08:35:04] *** Joins: waffles (wafflespean@moz-fdp.jmi.165.122.IP) [08:35:44] *** Joins: SurpriseTRex (STR@moz-u0o3if.in-addr.btopenworld.com) [08:37:25] *** Joins: dinfuehr (dinfuehr@moz-1v6.2no.31.85.IP) [08:37:56] *** Quits: stephen (user@moz-to5njc.m7k5.54kg.0101.2620.IP) (Ping timeout: 121 seconds) [08:38:29] *** Quits: galen (galen@moz-caprup.dsl-w.verizon.net) (Ping timeout: 121 seconds) [08:40:01] *** Joins: solidsnack (solidsnack@moz-kro69u.ca.comcast.net) [08:41:03] *** Joins: vadix (vadix@moz-jmj.0nm.219.24.IP) [08:41:13] *** Joins: enzlbtyn (Adium@moz-sua.l0d.104.58.IP) [08:42:18] *** Joins: demilux (demilux@moz-73qa6c.wa.comcast.net) [08:42:37] *** Joins: mgottschlag (quassel@moz-fd9i0e.hsi6.kabel-badenwuerttemberg.de) [08:42:39] *** Joins: ambaxter (ambaxter@moz-epl41q.res.rr.com) [08:43:15] *** Joins: firstdayonthejob (firstdayont@moz-bipmqq.cable.virginm.net) [08:43:19] *** Joins: Munksgaard (philip_munk@moz-26p.dgb.171.79.IP) [08:43:24] *** Quits: lishuo (lishuo@moz-aka.rdt.57.119.IP) (Connection closed) [08:44:07] *** Joins: stelarcf_ (stelarcf@moz-3gh.lb8.81.92.IP) [08:46:20] *** Quits: demilux (demilux@moz-73qa6c.wa.comcast.net) (Ping timeout: 121 seconds) [08:46:49] *** Quits: ambaxter (ambaxter@moz-epl41q.res.rr.com) (Ping timeout: 121 seconds) [08:46:51] *** Quits: jml (jml@moz-2uujnd.81.in-addr.arpa) (Ping timeout: 121 seconds) [08:47:19] *** Quits: adhoc (adhoc@moz-579fgj.internode.on.net) (Ping timeout: 121 seconds) [08:48:34] *** Joins: casey_ (casey@moz-v0ns05.tpgi.com.au) [08:48:50] *** Joins: larhat (Adium@moz-b0j39j.proc.ru) [08:49:10] *** Quits: agile (mike@moz-m71dqt.rcsntx.sbcglobal.net) (Connection closed) [08:49:25] *** Joins: jml (jml@moz-2uujnd.81.in-addr.arpa) [08:49:42] *** Joins: dzbarsky (Adium@moz-lsec1s.82pc.j76f.0646.2601.IP) [08:50:59] *** Quits: firstdayonthejob (firstdayont@moz-bipmqq.cable.virginm.net) (Quit: WeeChat 1.4-dev) [08:51:08] *** Joins: firstdayonthejob (firstdayont@moz-bipmqq.cable.virginm.net) [08:51:40] *** Quits: nebopolis (Mibbit@moz-btllu0.wi.charter.com) (Quit: http://www.mibbit.com ajax IRC Client) [08:51:52] *** Joins: lishuo (lishuo@moz-aka.rdt.57.119.IP) [08:51:56] *** Joins: latk (textual@moz-q2tvtg.cable.virginm.net) [08:52:00] *** Quits: lishuo (lishuo@moz-aka.rdt.57.119.IP) (Connection closed) [08:52:21] *** Joins: lishuo (lishuo@moz-aka.rdt.57.119.IP) [08:52:31] *** Joins: skade_ (skade@moz-0djl38.boh1-r2.syseleven.net) [08:52:37] *** Quits: casey_ (casey@moz-v0ns05.tpgi.com.au) (Ping timeout: 121 seconds) [08:52:44] *** Joins: agile (mike@moz-m71dqt.rcsntx.sbcglobal.net) [08:53:16] *** Joins: belst (belstgut@moz-kb8orj.sky-e.de) [08:53:23] *** Joins: Gabriel_7 (Gabriel@moz-po3t0n.loria.fr) [08:53:42] *** Joins: junqed (junqed@moz-j9m.kef.70.178.IP) [08:55:16] *** Joins: junqed_ (junqed@moz-9pe.2ap.70.178.IP) [08:55:20] *** Quits: skade (skade@moz-0djl38.boh1-r2.syseleven.net) (Ping timeout: 121 seconds) [08:56:23] *** Quits: enzlbtyn (Adium@moz-sua.l0d.104.58.IP) (Quit: Leaving.) [08:57:06] *** Joins: mpark (mpark@moz-3jo6j8.ca.comcast.net) [08:57:44] *** Quits: junqed (junqed@moz-j9m.kef.70.178.IP) (Ping timeout: 121 seconds) [08:58:40] *** Joins: mpark_ (mpark@moz-3jo6j8.ca.comcast.net) [08:58:40] *** Quits: mpark (mpark@moz-3jo6j8.ca.comcast.net) (Connection closed) [08:59:57] *** Joins: iceiceice (chris@moz-n3v1ju.ias.edu) [09:02:56] *** Quits: junqed_ (junqed@moz-9pe.2ap.70.178.IP) (A TLS packet with unexpected length was received.) [09:03:38] *** Joins: lambdanon (lambdanon@moz-9p3lhv.dip0.t-ipconnect.de) [09:03:59] *** Joins: cr (cr@moz-leundu.net) [09:04:20] How do we splitt up loooong string literals over multiple lines? Asking for a format!() of mine. (pnkfelix?) [09:04:37] *** Quits: Zr40work (zr40@moz-muqgjb.dynamic.ziggo.nl) (Quit: Textual IRC Client: www.textualapp.com) [09:05:11] cr: put a \ at the end of the line [09:05:19] it'll eat all the leading whitespace on the following line [09:05:24] *** Joins: Zr40work (zr40@moz-muqgjb.dynamic.ziggo.nl) [09:05:26] *** Quits: Gamecubic (cubic@moz-bglmk5.mc.videotron.ca) (Quit: Leaving) [09:06:01] *** Quits: tikue (tikue@moz-u6dt3k.ca.comcast.net) (Connection closed) [09:07:30] *** Joins: dmilith (dmilith@moz-8dkrre.interkar.pl) [09:08:06] *** Joins: ubsan__ (ubsan@moz-92sbjt.wa.comcast.net) [09:08:12] *** Quits: ubsan_ (ubsan@moz-92sbjt.wa.comcast.net) (Connection closed) [09:08:19] *** ubsan__ is now known as ubsan_ [09:08:56] *** Joins: orks (orks@moz-t1r.tom.44.37.IP) [09:09:51] *** zz_NameNotFound is now known as NameNotFound [09:10:17] *** Quits: blank_name (blank_name@moz-glkek8.mi.frontiernet.net) (Ping timeout: 121 seconds) [09:10:20] *** Joins: blank_name1 (blank_name@moz-349.ssl.183.192.IP) [09:11:05] *** Joins: brandonson (brandonson@moz-sunivd.bchsia.telus.net) [09:11:06] *** Quits: gopar (gopar@moz-5039uj.ca.comcast.net) (A TLS packet with unexpected length was received.) [09:12:47] *** Joins: ferjm (textual@moz-nvpjsv.dynamicIP.rima-tde.net) [09:12:50] Mutabah, interesting! Thanks! I'm nominating this one for the Weirdest Use of Backslash Award. :) [09:13:58] *** Joins: laumann (thomas@moz-3m6.3kq.109.2.IP) [09:14:21] *** Joins: Guest60563 (flo@moz-nq76bc.dclient.hispeed.ch) [09:14:54] Mutabah: Interesting, I thought it just escaped the newline. [09:15:26] I'd just try running the lines together. [09:15:31] "first line" "next line" [09:15:44] it's not even a new thing... C, $SHELL etc have been doing it for ages [09:15:45] *** Quits: dzbarsky (Adium@moz-lsec1s.82pc.j76f.0646.2601.IP) (Quit: Leaving.) [09:15:45] It works in like dozen other languages. [09:19:10] Xion: Rust doesn't do concatenation of literals like that [09:19:17] THat said, the concat! macro does that [09:19:37] *** Joins: shadower (shadower@moz-3ah4n5.osop.rhcloud.com) [09:20:25] *** NameNotFound is now known as zz_NameNotFound [09:20:55] *** Quits: jonmorehouse (jonmorehous@moz-i7q3gp.uljc.uk63.6000.2606.IP) (Ping timeout: 121 seconds) [09:21:22] halcyon: it probably just requires wiring up the library internals to each other, unfortunately I don’t know of any effort to do so [09:23:13] *** Joins: Alek (textual@moz-hivpjb.bb.online.no) [09:23:20] The reason why we *don't* do what C does is because the C way is prone to errors when you miss commas or similar. [09:23:45] in Rust ["foo" "bar"] is a syntax error, in C it's fine. [09:24:07] *** Joins: oli_obk_ (smuxi@moz-um2.0sb.52.141.IP) [09:25:26] *** Joins: sepp2k (sepp2k@moz-69go6a.isp.uni-luebeck.de) [09:25:42] *** Joins: adhoc (adhoc@moz-579fgj.internode.on.net) [09:27:40] *** Quits: lnostdal_ (lnostdal@moz-nc66ho.dsl.telepac.pt) (Ping timeout: 121 seconds) [09:30:00] *** Joins: forgottenone (forgottenon@moz-il2.e4m.40.176.IP) [09:30:09] *** Quits: mgottschlag (quassel@moz-fd9i0e.hsi6.kabel-badenwuerttemberg.de) (Ping timeout: 121 seconds) [09:30:41] *** Quits: larhat (Adium@moz-b0j39j.proc.ru) (Quit: Leaving.) [09:31:00] *** Joins: Ms2ger (Ms2ger@moz-dkoo7a.access.telenet.be) [09:31:03] *** Joins: AlisdairO (anonymous@moz-ntsaoe.cable.virginm.net) [09:31:25] *** Joins: blackgoat (blackgoat@moz-stj.iu0.157.221.IP) [09:31:28] *** Joins: ebel (rory@moz-l1ldq7.hsi4.kabel-badenwuerttemberg.de) [09:34:56] *** Quits: AlisdairO (anonymous@moz-ntsaoe.cable.virginm.net) (Client exited) [09:35:31] *** Quits: aravindavk (aravinda@moz-m6j.f0d.244.121.IP) (Ping timeout: 121 seconds) [09:35:37] *** Quits: mpark_ (mpark@moz-3jo6j8.ca.comcast.net) (Quit: My Mac has gone to sleep. ZZZzzz…) [09:36:30] *** Quits: dpc (dpc@moz-j55hov.ahkg.bqct.0647.2601.IP) (Ping timeout: 121 seconds) [09:36:37] *** Quits: xrash (smuxi@moz-1ddof8.telesp.net.br) (Connection closed) [09:37:34] *** Quits: zacstewa1t (zacstewart@moz-qi6qci.ga.comcast.net) (Ping timeout: 121 seconds) [09:38:05] *** Joins: aravindavk (aravinda@moz-m6j.f0d.244.121.IP) [09:38:09] *** Joins: robotblake (robotblake@moz-0v636k.wa.comcast.net) [09:38:11] *** Quits: firstdayonthejob (firstdayont@moz-bipmqq.cable.virginm.net) (Ping timeout: 121 seconds) [09:38:52] *** Quits: aravindavk (aravinda@moz-m6j.f0d.244.121.IP) (Quit: Konversation terminated!) [09:39:28] *** Quits: alonlevy (alon@moz-nbi.32h.154.31.IP) (Ping timeout: 121 seconds) [09:40:56] *** Quits: dmilith (dmilith@moz-8dkrre.interkar.pl) (Quit: My Mac has gone to sleep. ZZZzzz…) [09:41:24] *** Joins: mpark (mpark@moz-3jo6j8.ca.comcast.net) [09:43:12] *** Joins: demilux (demilux@moz-73qa6c.wa.comcast.net) [09:44:14] *** Joins: seriyPS (seriy@moz-8fj.1a0.172.178.IP) [09:45:46] *** Quits: lishuo (lishuo@moz-aka.rdt.57.119.IP) (Connection closed) [09:46:57] *** Joins: rubdos (rubdos@moz-onikj8.dynamic.voo.be) [09:46:58] *** Quits: fyolnish (fyolnish@moz-jqsevj.ucom.ne.jp) (Connection closed) [09:47:15] *** Quits: demilux (demilux@moz-73qa6c.wa.comcast.net) (Ping timeout: 121 seconds) [09:48:13] *** Joins: fyolnish (fyolnish@moz-jqsevj.ucom.ne.jp) [09:48:38] *** Quits: fyolnish (fyolnish@moz-jqsevj.ucom.ne.jp) (Connection closed) [09:48:39] *** Joins: fyolnish (fyolnish@moz-jqsevj.ucom.ne.jp) [09:49:19] *** Joins: casey_ (casey@moz-v0ns05.tpgi.com.au) [09:53:22] *** Quits: casey_ (casey@moz-v0ns05.tpgi.com.au) (Ping timeout: 121 seconds) [09:54:27] *** Joins: Nextra (Nextra@moz-tikakb.ewe-ip-backbone.de) [09:54:28] *** Joins: areski (areski@moz-7o8r19.user.ono.com) [09:55:01] *** Joins: cruor99 (cruor99@moz-0os33h.customer.cdi.no) [09:55:14] *** Joins: AlisdairO (anonymous@moz-ntsaoe.cable.virginm.net) [09:56:00] aatch: ... what does that mean in C? [09:56:23] *** Quits: AlisdairO (anonymous@moz-ntsaoe.cable.virginm.net) (Client exited) [09:56:47] Manishearth: Compile time concatenation. [09:57:16] til [09:57:31] *** Quits: forgottenone (forgottenon@moz-il2.e4m.40.176.IP) (A TLS packet with unexpected length was received.) [09:57:53] *** Quits: dellavg (dellavg@moz-iva.9jl.232.95.IP) (A TLS packet with unexpected length was received.) [09:58:24] *** Joins: forgottenone (forgottenon@moz-il2.e4m.40.176.IP) [09:59:03] *** Quits: cruor99 (cruor99@moz-0os33h.customer.cdi.no) (Ping timeout: 121 seconds) [09:59:20] *** Joins: dellavg (dellavg@moz-iva.9jl.232.95.IP) [10:00:23] *** Quits: newbie (eibwen@moz-foett2.dip0.t-ipconnect.de) (Ping timeout: 121 seconds) [10:03:55] *** Quits: dellavg (dellavg@moz-iva.9jl.232.95.IP) (A TLS packet with unexpected length was received.) [10:04:12] *** Joins: dellavg (dellavg@moz-iva.9jl.232.95.IP) [10:04:32] *** Quits: cespare (cespare@moz-fc8h4f.compute-1.amazonaws.com) (Ping timeout: 121 seconds) [10:05:12] *** Quits: sepp2k (sepp2k@moz-69go6a.isp.uni-luebeck.de) (Quit: Leaving.) [10:05:30] *** Quits: forgottenone (forgottenon@moz-il2.e4m.40.176.IP) (Quit: Konversation terminated!) [10:06:06] *** Quits: fyolnish (fyolnish@moz-jqsevj.ucom.ne.jp) (Connection closed) [10:06:16] *** Joins: forgottenone (forgottenon@moz-il2.e4m.40.176.IP) [10:06:41] *** Quits: THIS-NICK-SUCKS (nan@moz-3fecuc.is.googolplex.ninja) (Ping timeout: 121 seconds) [10:06:41] *** Joins: fyolnish (fyolnish@moz-jqsevj.ucom.ne.jp) [10:06:58] *** Joins: martin-li (martin-li@moz-g4n.dql.118.123.IP) [10:10:01] *** Joins: sepp2k (sepp2k@moz-7t23nq.isp.uni-luebeck.de) [10:11:30] *** zz_NameNotFound is now known as NameNotFound [10:12:46] *** Joins: rkruppe (chatzilla@moz-3nj.rnu.131.95.IP) [10:12:50] *** Joins: lishuo (lishuo@moz-aka.rdt.57.119.IP) [10:15:03] *** Joins: jviereck (Adium@moz-egksnd.dclient.hispeed.ch) [10:16:34] *** Quits: lishuo (lishuo@moz-aka.rdt.57.119.IP) (Connection closed) [10:16:38] *** Joins: sifton (sifton@moz-p8hanb.cable.rogers.com) [10:17:58] *** Quits: makoLine (mako@moz-f9dvuh.flip.co.nz) (Ping timeout: 121 seconds) [10:18:07] *** Joins: sigma (sigma@moz-9epccp.cable.virginm.net) [10:18:15] *** Quits: mpark (mpark@moz-3jo6j8.ca.comcast.net) (Quit: My Mac has gone to sleep. ZZZzzz…) [10:19:49] *** Quits: dinfuehr (dinfuehr@moz-1v6.2no.31.85.IP) (Connection closed) [10:20:58] *** NameNotFound is now known as zz_NameNotFound [10:21:36] *** Quits: brandonson (brandonson@moz-sunivd.bchsia.telus.net) (Connection closed) [10:24:18] *** Joins: mneumann (Thunderbird@moz-00qv32.rz.uni-karlsruhe.de) [10:24:26] *** Quits: martin-li (martin-li@moz-g4n.dql.118.123.IP) (Ping timeout: 121 seconds) [10:25:41] *** Joins: dinfuehr (dinfuehr@moz-1v6.2no.31.85.IP) [10:26:16] *** Joins: mpark (mpark@moz-3jo6j8.ca.comcast.net) [10:27:06] *** Joins: mstevens (mstevens@moz-itk2jg.etla.org) [10:27:46] *** Quits: sifton (sifton@moz-p8hanb.cable.rogers.com) (Quit: My Mac has gone to sleep. ZZZzzz…) [10:28:25] *** Quits: Asandari (Asandari@moz-se3dme.cpe.pppoe.ca) (Ping timeout: 121 seconds) [10:29:41] *** Quits: Andoriyu (Andoriyu@moz-a9o6ej.res.rr.com) (Quit: Textual IRC Client: www.textualapp.com) [10:29:47] *** Joins: p32blo (p32blo@moz-gbnpoc.di.uminho.pt) [10:29:48] *** Joins: vmesons (rmacleod@moz-hs5cri.cable.teksavvy.com) [10:30:26] *** Joins: psd (uid62508@moz-6soqq9.richmond.irccloud.com) [10:30:46] *** Quits: mhcerri (mhcerri@moz-hnf.m94.138.177.IP) (Connection closed) [10:31:20] *** Joins: mhcerri (mhcerri@moz-hnf.m94.138.177.IP) [10:31:24] *** Quits: vmeson (rmacleod@moz-hs5cri.cable.teksavvy.com) (Ping timeout: 121 seconds) [10:33:23] *** Quits: jviereck (Adium@moz-egksnd.dclient.hispeed.ch) (Quit: Leaving.) [10:34:49] *** Quits: jellytux (jellytux@moz-cvkn0l.bredband.comhem.se) (Quit: leaving) [10:34:51] *** Joins: jellytux (jellytux@moz-cvkn0l.bredband.comhem.se) [10:34:53] *** Quits: fyolnish (fyolnish@moz-jqsevj.ucom.ne.jp) (Connection closed) [10:35:01] *** Joins: dextertzu (dexter@moz-mvcfdf.vs.shawcable.net) [10:35:14] *** Joins: Asandari (Asandari@moz-se3dme.cpe.pppoe.ca) [10:37:42] *** Quits: jellytux (jellytux@moz-cvkn0l.bredband.comhem.se) (Quit: leaving) [10:37:51] *** Joins: jellytux (jellytux@moz-cvkn0l.bredband.comhem.se) [10:38:39] *** Quits: sbw (Thunderbird@moz-gkj.r2e.173.59.IP) (Ping timeout: 121 seconds) [10:39:40] *** Joins: fyolnish (fyolnish@moz-jqsevj.ucom.ne.jp) [10:39:42] *** Quits: mpark (mpark@moz-3jo6j8.ca.comcast.net) (Quit: My Mac has gone to sleep. ZZZzzz…) [10:40:29] *** Quits: rkruppe (chatzilla@moz-3nj.rnu.131.95.IP) (Quit: ChatZilla 0.9.92 [Firefox 44.0.2/20160210153822]) [10:40:31] *** Joins: deadc0de (chsitter@moz-lrh.035.31.94.IP) [10:40:46] *** Joins: sbw (Thunderbird@moz-gkj.r2e.173.59.IP) [10:42:26] *** Quits: forgottenone (forgottenon@moz-il2.e4m.40.176.IP) (Quit: Konversation terminated!) [10:43:27] *** Joins: forgottenone (forgottenon@moz-il2.e4m.40.176.IP) [10:43:42] *** Quits: fyolnish (fyolnish@moz-jqsevj.ucom.ne.jp) (Ping timeout: 121 seconds) [10:44:03] *** Joins: demilux (demilux@moz-73qa6c.wa.comcast.net) [10:44:24] *** Joins: ambaxter (ambaxter@moz-epl41q.res.rr.com) [10:44:38] *** Joins: eap (eap@moz-chsqii.tpgi.com.au) [10:44:46] *** Quits: forgottenone (forgottenon@moz-il2.e4m.40.176.IP) (Quit: Konversation terminated!) [10:44:55] *** Joins: forgottenone (forgottenon@moz-il2.e4m.40.176.IP) [10:45:03] *** Joins: mgottschlag (quassel@moz-ffd4vr.qiv1.bbcb.1398.2a00.IP) [10:45:11] *** Quits: latk (textual@moz-q2tvtg.cable.virginm.net) (Quit: My Mac has gone to sleep. ZZZzzz…) [10:45:57] *** Quits: mindcat (mindcat@moz-p5v.5o5.118.113.IP) (Ping timeout: 121 seconds) [10:46:23] *** Joins: ubsan__ (ubsan@moz-92sbjt.wa.comcast.net) [10:47:08] *** Joins: aravindavk (aravinda@moz-m6j.f0d.244.121.IP) [10:47:08] *** Joins: deadc0de_ (chsitter@moz-lrh.035.31.94.IP) [10:47:20] *** Joins: mpark (mpark@moz-3jo6j8.ca.comcast.net) [10:48:26] *** Quits: ambaxter (ambaxter@moz-epl41q.res.rr.com) (Ping timeout: 121 seconds) [10:49:03] *** Quits: demilux (demilux@moz-73qa6c.wa.comcast.net) (Ping timeout: 121 seconds) [10:49:08] *** Joins: gal_bolle (florent@moz-81dkm2.univ-orleans.fr) [10:49:43] *** Quits: deadc0de (chsitter@moz-lrh.035.31.94.IP) (Ping timeout: 121 seconds) [10:50:08] *** Joins: casey_ (casey@moz-v0ns05.tpgi.com.au) [10:50:23] *** Joins: mkpankov (mkpankov@moz-h7j.4g4.103.91.IP) [10:50:33] *** Quits: ubsan__ (ubsan@moz-92sbjt.wa.comcast.net) (Ping timeout: 121 seconds) [10:51:08] *** Joins: martin-li (martin-li@moz-g4n.dql.118.123.IP) [10:51:30] *** Joins: shellac (pldms@moz-lngnj4.bris.ac.uk) [10:51:44] Anyone knows how to down cast an Any to some trait? [10:52:08] *** Joins: sheddow (sheddow@moz-2tmaov.3p.ntebredband.no) [10:52:14] martin-li: you can't, you can only cast it to a concrete type [10:52:29] *** Joins: klutzy (not@moz-0t8.piq.68.115.IP) [10:52:36] are you sure you need an `Any`? [10:53:22] *** Joins: mindcat (mindcat@moz-1f0.7sq.30.14.IP) [10:54:11] *** Quits: eric_lagergren (eric@moz-lr1hrn.wa.comcast.net) (Connection closed) [10:54:11] *** Quits: casey_ (casey@moz-v0ns05.tpgi.com.au) (Ping timeout: 121 seconds) [10:54:43] Actually I want to load some struct from some library dynamically. [10:55:19] martin-li, there's a bunch of crates for building a custom Any-like trait. [10:55:19] Something like load class from a jar in java. [10:55:24] *** Quits: sbw (Thunderbird@moz-gkj.r2e.173.59.IP) (Client exited) [10:55:59] martin-li, which is useful if you want to keep the downcast-to-concrete stuff, but also want other functionality. [10:56:26] martin-li: You can make the plugin return a Box directly [10:57:49] *** Quits: forgottenone (forgottenon@moz-il2.e4m.40.176.IP) (Quit: Konversation terminated!) [10:58:32] *** Joins: mindcat_ (mindcat@moz-uoc.7sq.30.14.IP) [10:58:46] *** Joins: forgottenone (forgottenon@moz-il2.e4m.40.176.IP) [10:58:56] *** Joins: sbw (Thunderbird@moz-gkj.r2e.173.59.IP) [10:59:34] *** Quits: mindcat (mindcat@moz-1f0.7sq.30.14.IP) (Ping timeout: 121 seconds) [10:59:39] *** Quits: mindcat_ (mindcat@moz-uoc.7sq.30.14.IP) (Quit: Lost terminal) [11:03:52] *** Joins: Nemo157 (nemo157@moz-lh27vv.dyn.nltelcom.net) [11:04:10] *** Quits: aidanhs (aidanhs@moz-417.5v2.4.81.IP) (Ping timeout: 121 seconds) [11:04:19] *** Quits: Nilabhra (nilabhra@moz-m6r.4ml.64.45.IP) (Connection closed) [11:05:47] *** Joins: aidanhs (aidanhs@moz-417.5v2.4.81.IP) [11:06:05] *** Quits: p32blo (p32blo@moz-gbnpoc.di.uminho.pt) (Quit: Leaving.) [11:06:16] *** Joins: tikue (tikue@moz-u6dt3k.ca.comcast.net) [11:07:29] *** Joins: alonlevy (alon@moz-nbi.32h.154.31.IP) [11:08:11] *** Quits: aravindavk (aravinda@moz-m6j.f0d.244.121.IP) (Connection closed) [11:08:11] *** Quits: mpark (mpark@moz-3jo6j8.ca.comcast.net) (Quit: My Mac has gone to sleep. ZZZzzz…) [11:08:26] *** Joins: aravindavk (aravinda@moz-m6j.f0d.244.121.IP) [11:10:23] *** Quits: tikue (tikue@moz-u6dt3k.ca.comcast.net) (Ping timeout: 121 seconds) [11:10:42] *** Quits: jml (jml@moz-2uujnd.81.in-addr.arpa) (Quit: ZNC - http://znc.in) [11:12:47] *** zz_NameNotFound is now known as NameNotFound [11:14:04] *** Quits: mgottschlag (quassel@moz-ffd4vr.qiv1.bbcb.1398.2a00.IP) (Ping timeout: 121 seconds) [11:14:09] *** Joins: latk (textual@moz-rlonfv.cam.ac.uk) [11:14:17] *** Joins: p32blo (p32blo@moz-gbnpoc.di.uminho.pt) [11:15:33] *** Quits: hyPiRion (jeannikl@moz-e7l.qoh.21.178.IP) (Ping timeout: 121 seconds) [11:15:47] *** Quits: fabiand (fabiand@moz-omrh14.dip0.t-ipconnect.de) (Quit: Verlassend) [11:15:51] *** Quits: forgottenone (forgottenon@moz-il2.e4m.40.176.IP) (Connection closed) [11:15:53] *** Joins: dzbarsky (Adium@moz-v18mcd.ca.comcast.net) [11:15:58] *** Joins: FrozenCow (FrozenCow@moz-i2tvv4.chello.nl) [11:16:27] *** Joins: fabiand (fabiand@moz-6in4qd.dip0.t-ipconnect.de) [11:16:51] Given an array, which trait and how to implement it to make it printable? let x : [i32; 20] = [0; 20]; println!("{}", x); [11:16:52] *** Quits: tripped (trip@moz-i4845h.cable.mindspring.com) (Quit: Konversation terminated!) [11:17:30] *** Joins: pluton11x (q@moz-uu0cmf.dynamic.totbb.net) [11:19:46] *** Joins: leonardo2 (chatzilla@moz-ga01sp.retail.telecomitalia.it) [11:19:55] *** Quits: dzbarsky (Adium@moz-v18mcd.ca.comcast.net) (Ping timeout: 121 seconds) [11:20:10] *** Joins: mpark (mpark@moz-3jo6j8.ca.comcast.net) [11:20:44] *** Quits: xiinotulp (q@moz-pj4o8m.dynamic.totbb.net) (Ping timeout: 121 seconds) [11:20:58] Hello. I have done a small strategic mistake. [11:21:30] This thread is about an old but nice paper about some design problems of the SML language: https://www.reddit.com/r/programming/comments/47jd1u/a_critique_of_standard_ml/ [11:21:31] flavius: http://doc.rust-lang.org/std/fmt/trait.Display.html [11:21:56] flavius: but you won't be able to implement it for an array yourself, you'll need to wrap it in a newtype [11:22:10] So I've written a comment: https://www.reddit.com/r/programming/comments/47jd1u/a_critique_of_standard_ml/d0du72c [11:22:16] *** NameNotFound is now known as zz_NameNotFound [11:22:37] I have noted that Rust design seems to avoid most of the SML problems listed in the article [11:23:00] But my original short comment was not appreciated [11:23:21] So I think this time I've done a bad service for Rust :-( [11:23:28] Nemo157: Oh, ok. I've read about newtypes, they look like myType(u32), but how would they look for arrays? myType([i32; _])? [11:25:06] *** Joins: qwerty_nor (Thunderbird@moz-ar2hmo.adsl.cyfra.net) [11:25:37] *** Quits: eckhardt_ (eckhardt@moz-0b0.bm2.248.98.IP) (Connection closed) [11:25:40] And by the way, is Rust so different from SML that you can't even compare them? Perhaps my understanding of such matters is wrong after all... [11:26:00] flavius: I think you'd need to create one for each size as you can't be generic over a constant (yet) [11:26:22] *** Joins: lucian (lucian@moz-iuo.htl.74.194.IP) [11:26:28] limitations, limitations, limitations [11:26:30] flavius: alternatively you could create one for slices instead MyType(&[i32]) [11:26:48] flavius: alternatively, alternatively use Debug for printing [11:27:11] playbot-veno: let x = [1, 2]; println!("{:?}", x); [11:27:12] -playbot-veno- [1, 2] [11:27:12] -playbot-veno- () [11:27:12] *** Joins: kev (kevin_@moz-d13.2d2.41.5.IP) [11:28:03] Can anyone explain why adding a lifetime to this function breaks everything? http://is.gd/wfihC5 [11:28:04] *** Joins: julienXX_ (julienXX@moz-vrdhjo.abo.wanadoo.fr) [11:28:46] Nemo157: yeah, I'll just use Debug for now [11:28:52] *** Joins: eckhardt_ (eckhardt@moz-0b0.bm2.248.98.IP) [11:28:56] Nemo157: thanks [11:29:11] *** Quits: gal_bolle (florent@moz-81dkm2.univ-orleans.fr) (Ping timeout: 121 seconds) [11:29:33] *** Joins: casey_ (casey@moz-v0ns05.tpgi.com.au) [11:30:23] *** Joins: goyox86 (textual@moz-qfs.570.70.83.IP) [11:30:35] *** Quits: julienXX (julienXX@moz-vrdhjo.abo.wanadoo.fr) (Ping timeout: 121 seconds) [11:31:09] *** Quits: mpark (mpark@moz-3jo6j8.ca.comcast.net) (Quit: My Mac has gone to sleep. ZZZzzz…) [11:31:28] *** Joins: forgottenone (forgottenon@moz-kqh.omt.42.176.IP) [11:32:07] *** Quits: solidsnack (solidsnack@moz-kro69u.ca.comcast.net) (Quit: My Mac has gone to sleep. ZZZzzz…) [11:32:54] *** Quits: eckhardt_ (eckhardt@moz-0b0.bm2.248.98.IP) (Ping timeout: 121 seconds) [11:33:46] *** Joins: TimNN (TimNN@moz-r8l.9ss.89.141.IP) [11:34:06] *** Joins: SuperFluffy (janis@moz-19346r.physik.uni-potsdam.de) [11:34:14] kev, you're overconstraining the two lifetimes to be equal. If you show the more complicated code, we can try to make that work [11:35:14] Ms2ger: ah ok, I didn't think about it like that thanks! [11:35:29] *** Joins: lnostdal (lnostdal@moz-vkjnfp.dsl.telepac.pt) [11:35:32] the real code is waaaaaaay more complex, but essentially the same problem broken down [11:36:00] *** Joins: Diggsey (uid120933@moz-ob9ou8.brockwell.irccloud.com) [11:36:56] *** Quits: areski (areski@moz-7o8r19.user.ono.com) (Ping timeout: 121 seconds) [11:39:13] *** Joins: mpark (mpark@moz-3jo6j8.ca.comcast.net) [11:39:14] *** Joins: fyolnish (fyolnish@moz-8tfsb3.so-net.ne.jp) [11:39:31] *** Joins: lnostdal_ (lnostdal@moz-s6auuq.dsl.telepac.pt) [11:39:32] *** Quits: firemole (Thunderbird@moz-ok750a.thorcom.com) (Ping timeout: 121 seconds) [11:39:33] Well, see you later [11:39:35] *** Quits: leonardo2 (chatzilla@moz-ga01sp.retail.telecomitalia.it) (Quit: ChatZilla 0.9.92 [Firefox 44.0.2/20160210153822]) [11:40:21] *** Joins: pbor (paolo@moz-vfh.hnp.202.89.IP) [11:40:53] *** Joins: kmicu (kmicu@moz-uga.edn.218.91.IP) [11:41:13] *** Quits: aatch (james@moz-rat.omt.54.210.IP) (Ping timeout: 121 seconds) [11:42:23] *** Quits: lnostdal (lnostdal@moz-vkjnfp.dsl.telepac.pt) (Ping timeout: 121 seconds) [11:43:17] *** Quits: fyolnish (fyolnish@moz-8tfsb3.so-net.ne.jp) (Ping timeout: 121 seconds) [11:44:03] *** Joins: }ls{ (uhelp@moz-pgdv9t.dip0.t-ipconnect.de) [11:45:06] *** Joins: ambaxter (ambaxter@moz-epl41q.res.rr.com) [11:45:20] *** Joins: mgottschlag (quassel@moz-ffd4vr.qiv1.bbcb.1398.2a00.IP) [11:47:15] *** Joins: phil-opp (phil-opp@moz-ojmh9q.hsi13.kabel-badenwuerttemberg.de) [11:48:15] *** Quits: indefini (indefini@moz-4p4v25.ucom.ne.jp) (Connection closed) [11:49:21] What's the best way to convert a Box into an Arc? [11:49:22] *** Quits: ambaxter (ambaxter@moz-epl41q.res.rr.com) (Ping timeout: 121 seconds) [11:50:21] Arc::new(*my_box.into_raw()) ? [11:51:09] *** Quits: _Vi (vi@moz-bbs.vhj.131.104.IP) (Ping timeout: 121 seconds) [11:51:11] Yoric: Uhm, leave of the into_raw there [11:51:13] *** Quits: rubdos (rubdos@moz-onikj8.dynamic.voo.be) (Quit: Leaving) [11:51:22] *** Quits: arBmind (Andreas@moz-b51sut.adsl.alicedsl.de) (Quit: Leaving.) [11:51:26] I meant `*Box::into_raw(my_box)` [11:51:56] No into_raw business neccessary :) [11:52:07] Arc::new(*boxed_thing) [11:52:27] Ah, right. [11:52:28] *** Quits: sunng (nsun@moz-6pt.rd3.117.123.IP) (Ping timeout: 121 seconds) [11:52:38] That will work for Sized T, and for Unsized T its impossible anyway [11:52:39] Except neither seems to work because my `boxed_thing` doesn't implement Sized. [11:52:44] Oh, why? [11:52:54] I thought `Arc` could hold Unsized values? [11:53:15] Yeah [11:53:29] But you can't do Box -> Arc for unsized T [11:53:34] ... [11:53:36] * Yoric is sad. [11:53:48] Couldn't there be a `impl From> for Arc` that just steals the pointer? [11:53:53] *** Joins: _Vi (vi@moz-8kcf4a.3gli.01oh.0470.2001.IP) [11:53:56] *** Joins: andre_ (andre@moz-rnd.3qv.76.201.IP) [11:53:57] I think I filed an issue to support exactly that [11:53:57] Yoric: Arc stores the ref count in the same allocation, so you can not just reuse the allocated pointer of a Box. And creating a Arc with a usnized value requires to go through its its original sized value [11:55:19] In theory it might be possible to support dynamically allocating the right amount of memory with the right alignment, and copying over the data from a Box, but that requires API and specificationa round how unsized types work that are just not there yet [11:56:26] *** Joins: cruor99 (cruor99@moz-0os33h.customer.cdi.no) [11:57:29] *** Quits: mpark (mpark@moz-3jo6j8.ca.comcast.net) (Quit: My Mac has gone to sleep. ZZZzzz…) [11:57:31] *** Quits: mindtree (Mitch@moz-1auvn6.iprimus.net.au) (Ping timeout: 121 seconds) [11:58:56] It seems like Arc could be split into two heap allocations, one for the data and one for the counts, then it could reuse the Box's pointer for the data [11:59:06] In the Book, they switched from .ok().expect() to .expect(), but still write as though it's the former [11:59:07] "If we leave off calling these two methods, our program will compile, but we’ll get a warning: [11:59:08] " [11:59:40] Sure, but then you don't have Arc anymore but another design of reference counted smart pointer - which is totally fine, but would be backwards incompatible to change for the existing one [12:00:08] Sgeo_: File a bug or patch :) [12:00:28] *** Quits: cruor99 (cruor99@moz-0os33h.customer.cdi.no) (Ping timeout: 121 seconds) [12:01:11] *** Joins: espadrine (tyl@moz-gpr.c1p.152.213.IP) [12:01:17] kimundi, as an issue on the Rust project itself? The Book project seems to be for the new version [12:01:43] Sgeo_: An issue for whatever github repo the source of the book lives in, yeah [12:02:09] *** Joins: mpark (mpark@moz-3jo6j8.ca.comcast.net) [12:02:23] Sgeo_: Otherwise just ask steveklabnik how to proceed [12:02:52] *** Quits: mgottschlag (quassel@moz-ffd4vr.qiv1.bbcb.1398.2a00.IP) (Ping timeout: 121 seconds) [12:02:54] I should be asleep 6 hours ago [12:03:07] *** Joins: arBmind (Andreas@moz-6q36uk.dyn.telefonica.de) [12:03:31] heh [12:05:12] https://github.com/rust-lang/rust/issues/31912 [12:06:16] Looks good [12:06:34] *** Joins: Nilabhra (nilabhra@moz-kv6.uu1.171.203.IP) [12:07:31] *** Joins: adu (ajr@moz-99ult9.md.comcast.net) [12:08:51] *** Joins: areski (areski@moz-vh2nn3.dynamicIP.rima-tde.net) [12:09:40] *** Quits: adu (ajr@moz-99ult9.md.comcast.net) (Client exited) [12:11:07] *** Quits: khades_ (khades@moz-opi.h6q.74.212.IP) (Ping timeout: 121 seconds) [12:11:33] *** Joins: crunchiebones (jy@moz-5uf.jl4.74.188.IP) [12:13:29] *** zz_NameNotFound is now known as NameNotFound [12:16:09] *** Joins: Ketsuban (ketsuban@moz-l95gmi.fpgk.pom1.0c7d.2a02.IP) [12:16:26] *** Quits: mpark (mpark@moz-3jo6j8.ca.comcast.net) (Quit: My Mac has gone to sleep. ZZZzzz…) [12:18:23] *** Joins: demilux (demilux@moz-73qa6c.wa.comcast.net) [12:19:07] *** Quits: SuperFluffy (janis@moz-19346r.physik.uni-potsdam.de) (Ping timeout: 121 seconds) [12:21:18] *** Quits: deadc0de_ (chsitter@moz-lrh.035.31.94.IP) (Ping timeout: 121 seconds) [12:22:25] *** Quits: demilux (demilux@moz-73qa6c.wa.comcast.net) (Ping timeout: 121 seconds) [12:22:57] *** NameNotFound is now known as zz_NameNotFound [12:24:51] *** Joins: lnostdal__ (lnostdal@moz-96hmj7.dsl.telepac.pt) [12:25:38] *** Joins: mpark (mpark@moz-3jo6j8.ca.comcast.net) [12:26:21] *** Quits: forgottenone (forgottenon@moz-kqh.omt.42.176.IP) (Quit: Konversation terminated!) [12:27:45] *** Joins: forgottenone (forgottenon@moz-kqh.omt.42.176.IP) [12:27:58] *** Quits: lnostdal_ (lnostdal@moz-s6auuq.dsl.telepac.pt) (Ping timeout: 121 seconds) [12:28:33] *** Quits: sirGusWrk (Gustav@moz-bo7slh.sme.bredbandsbolaget.se) (Ping timeout: 121 seconds) [12:29:04] *** Joins: scriptor (scriptor@moz-19q800.res.rr.com) [12:29:20] *** Joins: firemole (Thunderbird@moz-ok750a.thorcom.com) [12:29:30] *** Quits: mpark (mpark@moz-3jo6j8.ca.comcast.net) (Quit: My Mac has gone to sleep. ZZZzzz…) [12:30:57] *** Quits: Nilabhra (nilabhra@moz-kv6.uu1.171.203.IP) (Ping timeout: 121 seconds) [12:31:06] *** Quits: ziad (ziad@moz-s65gmp.ca.comcast.net) (Client exited) [12:31:23] *** Joins: Nilabhra (nilabhra@moz-d83.2g6.242.103.IP) [12:31:39] *** Joins: mpark (mpark@moz-3jo6j8.ca.comcast.net) [12:32:16] *** Quits: mpark (mpark@moz-3jo6j8.ca.comcast.net) (Quit: My Mac has gone to sleep. ZZZzzz…) [12:33:06] *** Quits: scriptor (scriptor@moz-19q800.res.rr.com) (Ping timeout: 121 seconds) [12:33:23] *** Joins: paradigm (paradigm@moz-1ab.uf2.253.206.IP) [12:33:56] *** Joins: mpark (mpark@moz-3jo6j8.ca.comcast.net) [12:34:52] *** Joins: Morten (Morten@moz-ltrurg.bb.online.no) [12:35:06] *** Quits: TimNN (TimNN@moz-r8l.9ss.89.141.IP) (Quit: My Mac has gone to sleep. ZZZzzz…) [12:35:06] *** Joins: ubsan__ (ubsan@moz-92sbjt.wa.comcast.net) [12:35:31] *** Joins: nagisa_ (nagisa@moz-8t068g.static.zebra.lt) [12:35:39] *** Joins: awal (awal@moz-6ls.15i.98.14.IP) [12:35:41] *** nagisa_ is now known as nagisa [12:36:12] *** Quits: nagisa (nagisa@moz-8t068g.static.zebra.lt) (Client exited) [12:36:40] *** Quits: Ms2ger (Ms2ger@moz-dkoo7a.access.telenet.be) (Ping timeout: 121 seconds) [12:37:02] *** Joins: Shibe (Shibe@moz-m2e.ube.47.39.IP) [12:37:04] *** Joins: nagisa_ (nagisa@moz-8t068g.static.zebra.lt) [12:37:14] *** nagisa_ is now known as nagisa [12:37:24] why is this line erroring http://i.shibe.ml/QmR1WQkvikcjw7ztZPzznKzuoCE7545enzvPg2riWYFZQE.png http://i.shibe.ml/QmQC54Gu4TDfkGLqBYNncXdbnnkHEhE7MmoRnbGnP2bdnD.png [12:39:08] *** Quits: ubsan__ (ubsan@moz-92sbjt.wa.comcast.net) (Ping timeout: 121 seconds) [12:40:06] *** Quits: skade_ (skade@moz-0djl38.boh1-r2.syseleven.net) (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) [12:40:41] *** Joins: skade (skade@moz-0djl38.boh1-r2.syseleven.net) [12:42:50] *** Joins: futile (felix@moz-cursjl.unity-media.net) [12:43:57] *** Quits: aravindavk (aravinda@moz-m6j.f0d.244.121.IP) (Ping timeout: 121 seconds) [12:44:16] *** Quits: kev (kevin_@moz-d13.2d2.41.5.IP) (Ping timeout: 121 seconds) [12:44:26] Shibe: What type is Response? [12:44:40] enum [12:44:42] can we load or unload crate at runtime? [12:44:51] Shibe, put your code in http://play.rust-lang.org instead. [12:44:58] ok [12:45:08] Shibe: Give us the enum defintion. [12:45:22] http://is.gd/jiqooR [12:46:04] *** Quits: kmicu (kmicu@moz-uga.edn.218.91.IP) (Ping timeout: 121 seconds) [12:46:51] `Buffer([u8])` <- there is your [u8] that appeared in the error message [12:47:48] *** Quits: cpup (cpup@moz-v36.ktm.218.32.IP) (Ping timeout: 121 seconds) [12:48:52] martin-li: loading at runtime works with the dynamic linker as usual, but there is no infrastructure for runtime typechecks to load crates that where not part of the compilation process. unloading a crate likewise has the issue that there are no checks in place to ensure that it is actualy safe to do so [12:49:00] *** Quits: Kingsquee (kingsley@moz-3oducq.bchsia.telus.net) (Quit: https://i.imgur.com/qicT3GK.gif) [12:49:41] A toy project of me and eddyb is to figure out how to make both work, I should start writing a RFCs one of these days... [12:50:18] kimundi, is there a doc or something? [12:50:24] SneakySnake: oh [12:50:51] *** Quits: khades (Thunderbird@moz-opi.h6q.74.212.IP) (Client exited) [12:51:19] *** Joins: khades (Thunderbird@moz-opi.h6q.74.212.IP) [12:51:38] martin-li: For what is there, or for what me and eddyb have figured out so far? [12:52:32] The former is just the language docs about how to enable dynamic linking and then the linux/windows/etc specifc stuff for invoking the dynamic linker. The latter does not really have something written up in a central location [12:52:32] kimundi, what is there [12:52:32] *** Joins: khades_ (khades@moz-opi.h6q.74.212.IP) [12:53:07] *** Joins: Eisfreak7 (Eisfreak7@moz-0fg8sh.pools.vodafone-ip.de) [12:53:13] martin-li: There are crates like https://crates.io/crates/libloading for loading dynamic libraries [12:53:16] Sadly I haven't read the rust docs in ages, and have no idea where what is to find these days :) [12:53:17] when will you write a rfc? [12:53:54] But note that they don't have Rust-specific features. They are plain loaders for dynamic libraries. [12:54:15] You have to mark your exported functions #[no_mangle], so the symbols can be found properly [12:54:28] *** Joins: cpup (cpup@moz-o1p.e21.218.32.IP) [12:54:48] *** Joins: ansible1 (kvirc@moz-ks4ued.co.comcast.net) [12:54:49] martin-li: Depends on whether I find enough time and motivation for it. In theory right now is perfect scheduling wise for me, but I wouldn't hold your breath for something to be posted in the next weeks :) [12:54:58] well there is no stable ABI so any dynamic loading would need that? [12:56:18] Yeah, probably a stable ABI is a prerequisite for a complete solution for dynamically loadable crates. [12:56:34] *** Quits: stl (stl@moz-djk.ma5.15.176.IP) (Ping timeout: 121 seconds) [12:56:54] delma: Well, there is one guarantee that already exists (or used to exist at least), and that is that you can depend on separately compiled libraries in your code [12:57:12] As in, dependencies of your crate [12:57:49] *** Joins: cruor99 (cruor99@moz-0os33h.customer.cdi.no) [12:57:56] *** Quits: Nemo157 (nemo157@moz-lh27vv.dyn.nltelcom.net) (Ping timeout: 121 seconds) [12:58:41] In theory thats all you need: You define the common interfaces any runtime loadable crates would use as a external library and can then use it to indirectly communicate with whaeter else there exist in your application [13:00:47] I find that rustc itself use std::dynamic_lib::DynamicLibrary to load external libraries, which however is deprecated. [13:00:55] *** Quits: Alek (textual@moz-hivpjb.bb.online.no) (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) [13:01:06] *** Joins: Alek (textual@moz-hivpjb.bb.online.no) [13:01:20] *** Quits: mrt-prodz (mrt@moz-k58.1i9.73.188.IP) (Ping timeout: 121 seconds) [13:01:51] *** Quits: cruor99 (cruor99@moz-0os33h.customer.cdi.no) (Ping timeout: 121 seconds) [13:02:10] martin-li: There is no support for dynamic library loading in the standard library currently. You have to use external crates. [13:02:29] *** Quits: Nilabhra (nilabhra@moz-d83.2g6.242.103.IP) (Ping timeout: 121 seconds) [13:03:11] *** Joins: junqed (junqed@moz-9pe.2ap.70.178.IP) [13:03:25] *** Quits: rainemak (rainemak@moz-qhluil.gjaa.pi0p.0998.2001.IP) (Quit: Leaving) [13:03:29] martin-li: Thats basically just a internal custom solution, which is perfectly fine to do on your own. What is lacking is the support to define this in terms of generally safe reusable libraries [13:03:51] *** Joins: mrt-prodz (mrt@moz-k58.1i9.73.188.IP) [13:04:04] *** Joins: chriskrycho (chriskrycho@moz-rv50s0.res.rr.com) [13:05:41] *** Joins: jviereck (Adium@moz-e719ch.dip0.t-ipconnect.de) [13:06:34] *** Joins: SuperFluffy (janis@moz-19346r.physik.uni-potsdam.de) [13:06:53] *** Joins: rainemak (rainemak@moz-5do9kn.gjaa.pi0p.0998.2001.IP) [13:07:03] *** Joins: ato (sid11@moz-c1oek8.0j4i.jtu0.0101.2620.IP) [13:07:13] *** Quits: junqed (junqed@moz-9pe.2ap.70.178.IP) (Ping timeout: 121 seconds) [13:07:50] *** Joins: deadc0de (chsitter@moz-lrh.035.31.94.IP) [13:08:43] *** Joins: fl3 (fl3@moz-ghm.6bs.172.109.IP) [13:09:17] *** Quits: dinfuehr (dinfuehr@moz-1v6.2no.31.85.IP) (Connection closed) [13:09:18] *** Joins: smckay (steve@moz-ecf.05g.106.50.IP) [13:10:03] *** Quits: Guest60563 (flo@moz-nq76bc.dclient.hispeed.ch) (Ping timeout: 121 seconds) [13:12:05] *** Quits: FrozenCow (FrozenCow@moz-i2tvv4.chello.nl) (Ping timeout: 121 seconds) [13:12:23] *** Quits: p32blo (p32blo@moz-gbnpoc.di.uminho.pt) (Quit: Leaving.) [13:12:56] *** Quits: mpark (mpark@moz-3jo6j8.ca.comcast.net) (Quit: My Mac has gone to sleep. ZZZzzz…) [13:13:42] *** Joins: mgottschlag (quassel@moz-ffd4vr.qiv1.bbcb.1398.2a00.IP) [13:13:56] *** Quits: goyox86 (textual@moz-qfs.570.70.83.IP) (Quit: My Mac has gone to sleep. ZZZzzz…) [13:15:01] *** Quits: deadc0de (chsitter@moz-lrh.035.31.94.IP) (Ping timeout: 121 seconds) [13:16:54] *** Joins: dzbarsky (Adium@moz-jofl2r.82pc.j76f.0646.2601.IP) [13:17:20] *** Quits: jviereck (Adium@moz-e719ch.dip0.t-ipconnect.de) (Connection closed) [13:18:35] *** Quits: sleetdrop (sleetdrop@moz-pmb.klk.142.219.IP) (Ping timeout: 121 seconds) [13:19:03] *** Joins: stl (stl@moz-djk.ma5.15.176.IP) [13:19:19] Making dynamic library loading safe is super duper hard [13:19:32] *** Joins: meh (meh@moz-4v5.n5d.42.151.IP) [13:19:41] Especially unloading, that can open soundness holes [13:19:52] why are there so many implementations for the same type? http://i.shibe.ml/QmY9cnEKw6FnQH2WKshwgR8QK9HWgRfvXnVF23zuBC7XDa.png [13:20:09] because anything you get from that library which is 'static, once it unloads it no longer exists and dangling pointers everywhere [13:20:41] Shibe: I see different types on that screenshot you posted. [13:20:56] *** Quits: dzbarsky (Adium@moz-jofl2r.82pc.j76f.0646.2601.IP) (Ping timeout: 121 seconds) [13:21:21] *** Joins: rubdos (rubdos@moz-onikj8.dynamic.voo.be) [13:21:44] Shibe: Or rather: different associated types in PartialEq [13:22:13] yes but why do they hapen [13:22:15] In other words: there are many different implementations for very different types [13:22:19] why is it doing these 0-32 [13:22:22] Shibe: Because we don't have typelevel integers. [13:22:26] ok [13:22:28] (yet) [13:22:35] but will partialeq not work for anything bigger than 32? [13:22:37] len [13:22:52] You'd need to implement it. [13:23:02] https://github.com/rust-lang/rfcs/issues/1038 [13:23:42] Shibe: I don't fully understand why type-level integers are a big problem, but the RFC I linked discusses their implementation. [13:23:43] *** Quits: czarfacevillain (itsme@moz-n3s.5ll.54.210.IP) (Ping timeout: 121 seconds) [13:24:03] *** Quits: robotblake (robotblake@moz-0v636k.wa.comcast.net) (Quit: My Mac has gone to sleep. ZZZzzz…) [13:24:24] For a smart person here: why are type-level integers as proposed in RFC 1038 [1] hard? 1: https://github.com/rust-lang/rfcs/issues/1038 [13:25:00] [13:25:04] oops [13:25:34] *** Joins: Nilabhra (nilabhra@moz-d83.2g6.242.103.IP) [13:25:45] *** Joins: sogard (Mibbit@moz-bun.kgv.114.79.IP) [13:26:01] *** Joins: goyox86 (textual@moz-qfs.570.70.83.IP) [13:26:08] Hey, guys. What do you think about rustdoc adding to line coverage? [13:29:31] *** Joins: bluss (bluss@moz-rip51k.cust.bredbandsbolaget.se) [13:30:04] *** Quits: mkoskar (mkoskar@moz-f7r9kh.t7od.j6um.3b40.2a03.IP) (Ping timeout: 121 seconds) [13:31:24] *** Joins: TimNN (TimNN@moz-r8l.9ss.89.141.IP) [13:31:49] *** Quits: meh (meh@moz-4v5.n5d.42.151.IP) (Ping timeout: 121 seconds) [13:31:52] *** Quits: Morten (Morten@moz-ltrurg.bb.online.no) (Quit: http://www.kiwiirc.com/ - A hand crafted IRC client) [13:33:52] *** Quits: Nilabhra (nilabhra@moz-d83.2g6.242.103.IP) (Ping timeout: 121 seconds) [13:34:33] *** Joins: adu (ajr@moz-99ult9.md.comcast.net) [13:35:22] *** Quits: martin-li (martin-li@moz-g4n.dql.118.123.IP) (Quit: This computer has gone to sleep) [13:35:34] SuperFluffy: I wouldn't count myself as among the smart in that regard, but there are many possible designs for how to implement type integers, that all would conflict with each other or at least cause a inconsistent mess if combined [13:35:59] So its mostly a matter of figuring out _what_ to implement [13:36:21] *** Joins: Nilabhra (nilabhra@moz-d83.2g6.242.103.IP) [13:36:30] *** Quits: dextertzu (dexter@moz-mvcfdf.vs.shawcable.net) (Connection closed) [13:36:43] kimundi: Ok, smarter than me suffices for an answer. :-) [13:37:25] *** Joins: eLix (eLix@moz-unck9s.dynamic.kabel-deutschland.de) [13:38:46] *** Joins: sgflt (sgflt@moz-b7jm2s.dip0.t-ipconnect.de) [13:39:59] *** Joins: dinfuehr (dinfuehr@moz-1v6.2no.31.85.IP) [13:40:33] *** Quits: _Vi (vi@moz-8kcf4a.3gli.01oh.0470.2001.IP) (Ping timeout: 121 seconds) [13:41:06] *** Quits: adu (ajr@moz-99ult9.md.comcast.net) (Client exited) [13:43:33] *** crunchiebones is now known as help [13:43:38] *** help is now known as crunchiebones [13:46:34] *** Joins: ambaxter (ambaxter@moz-epl41q.res.rr.com) [13:46:50] *** Joins: miqid (miqid@moz-nq6js8.static.sl-reverse.com) [13:49:46] *** Quits: mhcerri (mhcerri@moz-hnf.m94.138.177.IP) (Connection closed) [13:50:02] *** Joins: amyers (amyers@moz-qn874b.zip.zayo.com) [13:50:36] *** Quits: ambaxter (ambaxter@moz-epl41q.res.rr.com) (Ping timeout: 121 seconds) [13:50:59] *** Joins: mhcerri (mhcerri@moz-hnf.m94.138.177.IP) [13:51:25] *** Quits: mhcerri (mhcerri@moz-hnf.m94.138.177.IP) (Connection closed) [13:51:43] *** Joins: gleb (gleb@moz-3ir1e8.rusanovka-net.kiev.ua) [13:52:48] *** Joins: mhcerri (mhcerri@moz-hnf.m94.138.177.IP) [13:53:27] *** Quits: mhcerri (mhcerri@moz-hnf.m94.138.177.IP) (Connection closed) [13:54:09] *** Joins: mhcerri (mhcerri@moz-hnf.m94.138.177.IP) [13:54:19] *** Quits: Alek (textual@moz-hivpjb.bb.online.no) (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) [13:55:17] *** Joins: urcra (urcra@moz-9lk9gn.cpe.webspeed.dk) [13:55:48] *** Quits: mhcerri (mhcerri@moz-hnf.m94.138.177.IP) (Connection closed) [13:56:18] *** Quits: dmac (dmac@moz-2ig65r.ca.comcast.net) (Connection closed) [13:56:32] *** Joins: tomprogrammer (thomas@moz-1mdfeg.tr5r.qept.4dd0.2001.IP) [13:56:53] has anyone used nom and can tell me how to refer to the full chain! when matching? [13:56:56] *** Joins: mhcerri (mhcerri@moz-hnf.m94.138.177.IP) [13:58:34] *** Joins: kmicu (kmicu@moz-uga.edn.218.91.IP) [13:59:19] *** Quits: psd (uid62508@moz-6soqq9.richmond.irccloud.com) (Quit: Connection closed for inactivity) [14:01:29] *** Quits: mhcerri (mhcerri@moz-hnf.m94.138.177.IP) (Connection closed) [14:01:45] *** Quits: phil-opp (phil-opp@moz-ojmh9q.hsi13.kabel-badenwuerttemberg.de) (Ping timeout: 121 seconds) [14:01:47] *** Joins: chris_99 (chris_99@moz-g2jhk1.clients.your-server.de) [14:02:00] *** zz_NameNotFound is now known as NameNotFound [14:02:09] *** Quits: blackgoat (blackgoat@moz-stj.iu0.157.221.IP) (Quit: WeeChat 1.4) [14:02:12] *** Joins: mhcerri (mhcerri@moz-hnf.m94.138.177.IP) [14:02:31] geal: ^ [14:02:32] *** Quits: urcra (urcra@moz-9lk9gn.cpe.webspeed.dk) (Connection closed) [14:02:37] *** Quits: mhcerri (mhcerri@moz-hnf.m94.138.177.IP) (Connection closed) [14:03:59] *** Joins: deadc0de (chsitter@moz-lrh.035.31.94.IP) [14:04:11] *** Joins: yuja (yuja@moz-fkgj36.so-net.ne.jp) [14:04:32] *** Joins: mhcerri (mhcerri@moz-hnf.m94.138.177.IP) [14:04:41] *** Joins: vadix_ (vadix@moz-ogk666.li8q.e9lr.b400.2607.IP) [14:04:47] *** Quits: mhcerri (mhcerri@moz-hnf.m94.138.177.IP) (Connection closed) [14:05:35] *** Joins: mhcerri (mhcerri@moz-hnf.m94.138.177.IP) [14:05:47] i've also asked in #nom, but it's a bit ... empty? [14:06:04] *** Quits: mhcerri (mhcerri@moz-hnf.m94.138.177.IP) (Connection closed) [14:06:18] is there a way to have cargo/rustc print out expanded macros? that'd help quite a bit as well [14:06:52] *** Joins: mhcerri (mhcerri@moz-hnf.m94.138.177.IP) [14:07:14] *** Quits: mhcerri (mhcerri@moz-hnf.m94.138.177.IP) (Connection closed) [14:07:51] *** Quits: skade (skade@moz-0djl38.boh1-r2.syseleven.net) (Ping timeout: 121 seconds) [14:08:02] *** Joins: mhcerri (mhcerri@moz-hnf.m94.138.177.IP) [14:08:29] *** Quits: mhcerri (mhcerri@moz-hnf.m94.138.177.IP) (Connection closed) [14:09:04] *** Joins: ksad (ksad@moz-oi4ckg.cnt.nerim.net) [14:09:30] how is to_owned() faster than to_string()? [14:09:32] and any benchmarks [14:09:32] *** Joins: mhcerri (mhcerri@moz-hnf.m94.138.177.IP) [14:09:46] *** Quits: mhcerri (mhcerri@moz-hnf.m94.138.177.IP) (Connection closed) [14:10:30] *** Joins: dextertzu (dexter@moz-mvcfdf.vs.shawcable.net) [14:10:35] *** Joins: mhcerri (mhcerri@moz-hnf.m94.138.177.IP) [14:11:02] *** Quits: mhcerri (mhcerri@moz-hnf.m94.138.177.IP) (Connection closed) [14:11:04] sgflt: https://doc.rust-lang.org/book/macros.html#debugging-macro-code [14:11:28] *** NameNotFound is now known as zz_NameNotFound [14:11:38] *** Joins: eap_ (eap@moz-chsqii.tpgi.com.au) [14:12:06] *** Joins: mhcerri (mhcerri@moz-hnf.m94.138.177.IP) [14:12:13] Shibe: .to_string() has a general implementation (for all types that have Display) [14:12:13] *** Joins: jeffbradberry (jrb@moz-mrjdh9.rlghnc.sbcglobal.net) [14:12:25] while .to_owned() is implemented specifically for String [14:12:31] *** Quits: mhcerri (mhcerri@moz-hnf.m94.138.177.IP) (Connection closed) [14:12:39] In a module, why does line 4 fail to resolve? What's the difference to line 3 (i.e. ::std:: compared to std::)? [14:12:47] 1: http://is.gd/Dfa3Sb [14:12:59] ^ the example playpen [14:13:03] SuperFluffy: ::std is an absolute path [14:13:18] *** Joins: mhcerri (mhcerri@moz-hnf.m94.138.177.IP) [14:13:20] just std:: searches for a submodule named "std" in your current module [14:13:23] so std:: is relative to the current module's namespace [14:13:36] *** Quits: mhcerri (mhcerri@moz-hnf.m94.138.177.IP) (Connection closed) [14:13:47] you could do `use std;` in the module [14:14:01] *** Quits: eap (eap@moz-chsqii.tpgi.com.au) (Ping timeout: 121 seconds) [14:14:17] And since my main() is the root, std:: ~ ::std:: ? [14:14:31] *** Joins: mhcerri (mhcerri@moz-hnf.m94.138.177.IP) [14:14:50] *** Quits: mhcerri (mhcerri@moz-hnf.m94.138.177.IP) (Connection closed) [14:15:29] *** Joins: larhat (Adium@moz-b0j39j.proc.ru) [14:15:38] *** Joins: mhcerri (mhcerri@moz-hnf.m94.138.177.IP) [14:16:03] yes [14:16:07] *** Quits: mhcerri (mhcerri@moz-hnf.m94.138.177.IP) (Connection closed) [14:16:20] Does a “use somemod” in a module foo then look for somemod in the namespace one level up? [14:16:20] it's just like "extern crate std;" was in the crate root [14:16:23] (and it is) [14:16:34] `use` uses absolute paths [14:16:44] unless prefixing with super:: or self:: [14:16:46] Aha, good to know. [14:17:03] *** Joins: mhcerri (mhcerri@moz-hnf.m94.138.177.IP) [14:17:18] *** Quits: mhcerri (mhcerri@moz-hnf.m94.138.177.IP) (Connection closed) [14:17:45] *** Quits: mvyskocil (mvyskocil@moz-1fo.p0p.7.31.IP) (Ping timeout: 121 seconds) [14:17:57] *** Joins: jamesmacaulay (jamesmacaul@moz-s6ajs1.cable.rogers.com) [14:18:09] *** Joins: mhcerri (mhcerri@moz-hnf.m94.138.177.IP) [14:18:25] *** Quits: Nilabhra (nilabhra@moz-d83.2g6.242.103.IP) (Ping timeout: 121 seconds) [14:18:27] Right, so: use foo == use ::foo; use super::foo <-- Look in your parent-module; use self::foo <-- Look in your current namespace. [14:18:34] *** Quits: mhcerri (mhcerri@moz-hnf.m94.138.177.IP) (Connection closed) [14:18:49] *** Quits: steffengy (quassel@moz-pkkjvs.dip0.t-ipconnect.de) (Ping timeout: 121 seconds) [14:19:12] *** Joins: Nemo157 (nemo157@moz-n8c.b85.166.46.IP) [14:19:13] *** Joins: steffengy (quassel@moz-kiq3gu.dip0.t-ipconnect.de) [14:19:32] *** Joins: mhcerri (mhcerri@moz-hnf.m94.138.177.IP) [14:19:51] *** Quits: mhcerri (mhcerri@moz-hnf.m94.138.177.IP) (Connection closed) [14:20:15] *** Joins: Nilabhra (nilabhra@moz-d83.2g6.242.103.IP) [14:20:21] *** Quits: latk (textual@moz-rlonfv.cam.ac.uk) (Ping timeout: 121 seconds) [14:20:33] *** Joins: mhcerri (mhcerri@moz-hnf.m94.138.177.IP) [14:20:38] *** Joins: jviereck (Adium@moz-e719ch.dip0.t-ipconnect.de) [14:20:44] *** Quits: mhcerri (mhcerri@moz-hnf.m94.138.177.IP) (Connection closed) [14:20:56] *** Quits: amyers (amyers@moz-qn874b.zip.zayo.com) (Connection closed) [14:21:06] *** Joins: amyers (amyers@moz-qn874b.zip.zayo.com) [14:21:12] yes [14:21:32] *** Joins: mhcerri (mhcerri@moz-hnf.m94.138.177.IP) [14:21:48] *** Quits: sbw (Thunderbird@moz-gkj.r2e.173.59.IP) (Client exited) [14:21:49] *** Quits: mhcerri (mhcerri@moz-hnf.m94.138.177.IP) (Connection closed) [14:22:31] *** Joins: mvyskocil (mvyskocil@moz-1fo.p0p.7.31.IP) [14:22:34] *** Joins: latk (textual@moz-rlonfv.cam.ac.uk) [14:22:36] *** Joins: mhcerri (mhcerri@moz-hnf.m94.138.177.IP) [14:22:41] *** Joins: Ms2ger (Ms2ger@moz-hfkmvr.access.telenet.be) [14:22:43] sogard: thank you [14:22:53] *** Quits: mhcerri (mhcerri@moz-hnf.m94.138.177.IP) (Connection closed) [14:22:53] *** Joins: ubsan__ (ubsan@moz-92sbjt.wa.comcast.net) [14:22:53] *** Quits: ogi (Ognyan@moz-idb.ot3.40.84.IP) (Quit: Leaving) [14:23:26] *** Quits: chriskrycho (chriskrycho@moz-rv50s0.res.rr.com) (Ping timeout: 121 seconds) [14:23:33] *** Joins: mhcerri (mhcerri@moz-hnf.m94.138.177.IP) [14:23:51] *** Quits: mhcerri (mhcerri@moz-hnf.m94.138.177.IP) (Connection closed) [14:25:11] *** Quits: jamesmacaulay (jamesmacaul@moz-s6ajs1.cable.rogers.com) (Ping timeout: 121 seconds) [14:25:25] *** Quits: Nilabhra (nilabhra@moz-d83.2g6.242.103.IP) (Ping timeout: 121 seconds) [14:25:59] *** Joins: sirGusWrk (Gustav@moz-bo7slh.sme.bredbandsbolaget.se) [14:26:07] *** Joins: Nilabhra (nilabhra@moz-d83.2g6.242.103.IP) [14:26:39] *** Quits: ansible1 (kvirc@moz-ks4ued.co.comcast.net) (Ping timeout: 121 seconds) [14:26:50] *** Joins: iiddnn_ (iacopodeeno@moz-j3t.57d.233.95.IP) [14:27:07] *** Quits: ubsan__ (ubsan@moz-92sbjt.wa.comcast.net) (Ping timeout: 121 seconds) [14:27:19] *** Quits: mvyskocil (mvyskocil@moz-1fo.p0p.7.31.IP) (Ping timeout: 121 seconds) [14:28:14] *** Joins: mkoskar (mkoskar@moz-f7r9kh.t7od.j6um.3b40.2a03.IP) [14:28:47] *** Quits: rubdos (rubdos@moz-onikj8.dynamic.voo.be) (Ping timeout: 121 seconds) [14:28:48] *** Quits: chris_99 (chris_99@moz-g2jhk1.clients.your-server.de) (Ping timeout: 121 seconds) [14:31:18] *** Joins: pastoraleman (pastoralema@moz-8ih0dv.cable.virginm.net) [14:31:29] *** Joins: FrozenCow (FrozenCow@moz-i2tvv4.chello.nl) [14:31:30] *** Joins: chriskrycho (chriskrycho@moz-rv50s0.res.rr.com) [14:31:38] *** Joins: mvyskocil (mvyskocil@moz-1fo.p0p.7.31.IP) [14:32:53] Shibe: to_string() has a general implementation that is no optimal if you know the exact output already - like in the case of strings. However, with the specialization feature the language just got, that difference will likely disappear in the future [14:33:06] ok [14:35:22] *** Joins: nadirs (nadirs@moz-2oq4ol.retail.telecomitalia.it) [14:35:41] *** Quits: mvyskocil (mvyskocil@moz-1fo.p0p.7.31.IP) (Ping timeout: 121 seconds) [14:36:37] *** Quits: keeper (keeper@moz-ugb.sk0.231.216.IP) (Ping timeout: 121 seconds) [14:36:54] *** Quits: deadc0de (chsitter@moz-lrh.035.31.94.IP) (Ping timeout: 121 seconds) [14:38:13] *** Joins: ansible1 (kvirc@moz-ks4ued.co.comcast.net) [14:39:18] *** Joins: mvyskocil (mvyskocil@moz-1fo.p0p.7.31.IP) [14:40:36] *** Joins: deadc0de (chsitter@moz-lrh.035.31.94.IP) [14:40:59] *** Joins: jamesmacaulay (jamesmacaul@moz-s6ajs1.cable.rogers.com) [14:41:06] hi all! Would it be possible to use a variable after it was moved? For example: here's what I try to achieve: [14:41:10] https://irccloud.mozilla.com/pastebin/GV5rpJmT [14:41:41] jlorenzo: Yes, clone() it. Or #[derive(Clone, Copy)]. [14:42:46] If you add Copy to MyStruct, it will do a copy if you want to use the value AFTER it is moved. [14:43:02] sogard: hmmm, the use case I'm trying to solve needs to keep the same object [14:43:59] jlorenzo: Generally, if your type is a moving type then using a variable of its type after a move is impossible. Only option is to not move, either by implementing clone() and calling it, or by also implementing Copy and have the compiler do copies instead of moves [14:44:01] sogard: MyStruct is actually a Stub, and I'm trying to see if it was called [14:44:05] *** Quits: Shibe (Shibe@moz-m2e.ube.47.39.IP) (Ping timeout: 121 seconds) [14:44:25] Then you have to send &MyStruct. [14:44:31] *** Joins: chris_99 (chris_99@moz-g2jhk1.clients.your-server.de) [14:44:41] Or any other pointer type. [14:45:17] *** Quits: mvyskocil (mvyskocil@moz-1fo.p0p.7.31.IP) (Ping timeout: 121 seconds) [14:45:20] Or do something like working with a Option and Option::take(), to make the move a runtime-queryable thing [14:45:24] *** Joins: Shibe (Shibe@moz-00a.qn1.47.39.IP) [14:45:51] *** Quits: chriskrycho (chriskrycho@moz-rv50s0.res.rr.com) (Ping timeout: 121 seconds) [14:46:09] *** Joins: mvyskocil (mvyskocil@moz-1fo.p0p.7.31.IP) [14:46:13] *** Joins: chriskrycho (chriskrycho@moz-rv50s0.res.rr.com) [14:46:15] *** Joins: phil-opp (phil-opp@moz-ojmh9q.hsi13.kabel-badenwuerttemberg.de) [14:46:34] *** Joins: stoner (stoner@moz-d8863v.redhat.com) [14:46:36] jlorenzo: Rust is not a dynamic and very reflective language. You don't have so much flexibility when it comes to testing. [14:46:55] jlorenzo: If its a stub that you have full control over, then you can also approach this with shared ownership - your MyStruct would still move, but you would have some other object that has a "backchannel" into it that you can sue to query it [14:47:01] does ::someobj import someobj from the current crate [14:47:33] Shibe: ::foo paths look up foo in the crate root, as opposed to just foo which look it up in the current module [14:48:14] This is anywhere outside "use" though. In "use", both ::foo and foo do the same thing [14:48:22] *** Joins: demilux (demilux@moz-73qa6c.wa.comcast.net) [14:48:24] kimundi: how do we achieve shared ownership? Is it with a combination of Rc and RefCell? [14:48:24] (And that is looking it up in the crate root) [14:49:08] jlorenzo: Yes, but then you have to change the signature of new() too. [14:49:17] jlorenzo: Your struct would be or contain a Rc<> (or actuelly depending on what you do it could also just be a & or &mut), and the method would use it to set some state [14:49:20] sogard: pointers => I'd prefer to not change the type in the signature, but I'll keep them in mind :) [14:49:58] *** Joins: Mermi (uid96745@moz-v9qrgi.richmond.irccloud.com) [14:50:15] *** Joins: musiKk (foobar@moz-ecd8ku.pools.vodafone-ip.de) [14:50:22] *** Quits: phil-opp (phil-opp@moz-ojmh9q.hsi13.kabel-badenwuerttemberg.de) (Ping timeout: 121 seconds) [14:51:31] *** Quits: vadix_ (vadix@moz-ogk666.li8q.e9lr.b400.2607.IP) (Ping timeout: 121 seconds) [14:51:52] *** Joins: ambaxter (ambaxter@moz-epl41q.res.rr.com) [14:52:24] *** Quits: demilux (demilux@moz-73qa6c.wa.comcast.net) (Ping timeout: 121 seconds) [14:52:44] *** Joins: mattrudder (textual@moz-ar6k2i.ca.astound.net) [14:54:22] *** Quits: futile (felix@moz-cursjl.unity-media.net) (Quit: WeeChat 1.4) [14:54:35] *** Quits: SurpriseTRex (STR@moz-u0o3if.in-addr.btopenworld.com) (Connection closed) [14:55:14] *** Quits: tristans1 (tristanseif@moz-aqblut.res.rr.com) (Ping timeout: 121 seconds) [14:55:45] *** ferjm is now known as ferjm|brb [14:55:57] *** Quits: ambaxter (ambaxter@moz-epl41q.res.rr.com) (Ping timeout: 121 seconds) [14:56:16] *** Quits: musiKk (foobar@moz-ecd8ku.pools.vodafone-ip.de) (Ping timeout: 121 seconds) [14:58:36] *** Joins: vadix_ (vadix@moz-ogk666.li8q.e9lr.b400.2607.IP) [14:58:59] *** Joins: cruor99 (cruor99@moz-0os33h.customer.cdi.no) [14:59:20] *** Joins: phil-opp (phil-opp@moz-ojmh9q.hsi13.kabel-badenwuerttemberg.de) [14:59:54] *** Joins: ahal (ahal@moz-b8e0a0.cpe.pppoe.ca) [15:00:28] *** Quits: arjun_ (arjun@moz-702.hmn.165.122.IP) (Ping timeout: 121 seconds) [15:00:41] *** Quits: pbor (paolo@moz-vfh.hnp.202.89.IP) (Ping timeout: 121 seconds) [15:00:50] *** Joins: futile (felix@moz-cursjl.unity-media.net) [15:01:18] *** Quits: mattrudder (textual@moz-ar6k2i.ca.astound.net) (Quit: My Mac has gone to sleep. ZZZzzz…) [15:02:39] *** zz_NameNotFound is now known as NameNotFound [15:03:01] *** Quits: cruor99 (cruor99@moz-0os33h.customer.cdi.no) (Ping timeout: 121 seconds) [15:03:48] *** Quits: mvyskocil (mvyskocil@moz-1fo.p0p.7.31.IP) (Ping timeout: 121 seconds) [15:04:03] *** Quits: tennix (vagrant@moz-kjb.7qo.39.106.IP) (Ping timeout: 121 seconds) [15:04:52] *** Joins: hyPiRion (jeannikl@moz-e7l.qoh.21.178.IP) [15:06:23] *** Joins: ubsan__ (ubsan@moz-92sbjt.wa.comcast.net) [15:06:51] *** Joins: nchambers (nchambers@moz-oa18l1.duckdns.org) [15:07:13] *** Quits: ubsan_ (ubsan@moz-92sbjt.wa.comcast.net) (Quit: <3) [15:07:22] *** ubsan__ is now known as ubsan_ [15:08:10] *** Quits: futile (felix@moz-cursjl.unity-media.net) (Quit: WeeChat 1.4) [15:08:18] *** Joins: futile (felix@moz-cursjl.unity-media.net) [15:08:41] So, any ideas on rustdoc line coverage? [15:09:24] *** Joins: mvyskocil (mvyskocil@moz-1fo.p0p.7.31.IP) [15:10:02] *** Ms2ger is now known as Ms2ger|mtg [15:10:33] *** Joins: anjumkaiser (anjumkaiser@moz-fk3.apv.50.39.IP) [15:11:41] *** Quits: Munksgaard (philip_munk@moz-26p.dgb.171.79.IP) (Connection closed) [15:12:07] *** NameNotFound is now known as zz_NameNotFound [15:12:34] *** Quits: phil-opp (phil-opp@moz-ojmh9q.hsi13.kabel-badenwuerttemberg.de) (Ping timeout: 121 seconds) [15:13:25] *** Quits: michaelgg (Mibbit@moz-c6r.kp9.216.201.IP) (Quit: http://www.mibbit.com ajax IRC Client) [15:15:23] *** Joins: pbor (paolo@moz-ndn.buu.60.151.IP) [15:16:37] I wonder if the Rust oracle will provide information for semantic highlighting [15:16:52] *** Quits: nadirs (nadirs@moz-2oq4ol.retail.telecomitalia.it) (Ping timeout: 121 seconds) [15:16:55] *** Joins: scriptor (scriptor@moz-19q800.res.rr.com) [15:17:21] *** Quits: KarolisK (karolis@moz-gvd.m2s.249.89.IP) (Connection closed) [15:17:37] *** Joins: dzbarsky (Adium@moz-v18mcd.ca.comcast.net) [15:18:35] *** Quits: anjumkaiser (anjumkaiser@moz-fk3.apv.50.39.IP) (Ping timeout: 121 seconds) [15:18:57] e.g. different syntax highlighting for traits and structs. Simple parsing cannot differentiate whether T in &T is a trait or a struct. [15:19:14] *** Joins: croyd (croyd@moz-3bf3hs.cable.rcn.com) [15:19:51] *** Joins: anjumkaiser (anjumkaiser@moz-fk3.apv.50.39.IP) [15:21:30] *** Joins: Alek (textual@moz-hivpjb.bb.online.no) [15:21:44] *** Quits: dzbarsky (Adium@moz-v18mcd.ca.comcast.net) (Ping timeout: 121 seconds) [15:23:04] *** Joins: Noldorin (noldorin@moz-l5a.oum.207.90.IP) [15:24:13] *** Quits: pbor (paolo@moz-ndn.buu.60.151.IP) (Ping timeout: 121 seconds) [15:25:21] *** Joins: orangeshark (erik@moz-pdc35c.44tj.56ot.0306.2602.IP) [15:27:31] *** Quits: jviereck (Adium@moz-e719ch.dip0.t-ipconnect.de) (Quit: Leaving.) [15:27:37] *** Quits: Eisfreak7 (Eisfreak7@moz-0fg8sh.pools.vodafone-ip.de) (Quit: WeeChat 1.4) [15:28:00] *** Joins: brianloveswords (brianlovesw@moz-bvav7m.fios.verizon.net) [15:29:43] *** Joins: ambaxter (ambaxter@moz-n7f.m5v.202.74.IP) [15:30:25] *** Quits: jamesmacaulay (jamesmacaul@moz-s6ajs1.cable.rogers.com) (Quit: My Mac has gone to sleep. ZZZzzz…) [15:30:59] *** jryans is now known as jryans|away [15:31:16] *** Quits: areski (areski@moz-vh2nn3.dynamicIP.rima-tde.net) (Ping timeout: 121 seconds) [15:31:52] *** Joins: annodomini (lambda@moz-qgii5v.ma.comcast.net) [15:32:55] *** Quits: ubsan_ (ubsan@moz-92sbjt.wa.comcast.net) (Connection closed) [15:33:01] *** Quits: waffles (wafflespean@moz-fdp.jmi.165.122.IP) (Quit: C'yall later...) [15:33:36] *** Joins: jdm (jdm@moz-mu9.06r.98.75.IP) [15:33:36] *** ChanServ sets mode: +o jdm [15:33:53] *** Quits: ambaxter (ambaxter@moz-n7f.m5v.202.74.IP) (Ping timeout: 121 seconds) [15:35:20] *** Quits: mvyskocil (mvyskocil@moz-1fo.p0p.7.31.IP) (Ping timeout: 121 seconds) [15:35:37] *** Joins: sbeckeriv (becker@moz-cg0maa.tukw.qwest.net) [15:35:43] *** Quits: latk (textual@moz-rlonfv.cam.ac.uk) (Quit: My Mac has gone to sleep. ZZZzzz…) [15:36:28] *** ferjm|brb is now known as ferjm [15:36:42] *** Joins: latk (textual@moz-rlonfv.cam.ac.uk) [15:37:03] *** Joins: pbor (paolo@moz-vfh.hnp.202.89.IP) [15:38:02] *** Quits: Shibe (Shibe@moz-00a.qn1.47.39.IP) (A TLS packet with unexpected length was received.) [15:39:32] *** Quits: forgottenone (forgottenon@moz-kqh.omt.42.176.IP) (Quit: Konversation terminated!) [15:40:58] *** Joins: tromey (tromey@moz-s93niv.hlrn.qwest.net) [15:41:51] *** Quits: sbeckeriv (becker@moz-cg0maa.tukw.qwest.net) (Client exited) [15:43:12] *** Joins: areski (areski@moz-fvk8de.dynamic.jazztel.es) [15:43:56] *** Joins: chc4 (chc4@moz-jp1i28.biz.rr.com) [15:44:10] *** Joins: samx (sami@moz-oq8dni.dyn.optonline.net) [15:44:53] *** Quits: anjumkaiser (anjumkaiser@moz-fk3.apv.50.39.IP) (Ping timeout: 121 seconds) [15:45:25] *** Joins: anjumkaiser (anjumkaiser@moz-fk3.apv.50.39.IP) [15:46:48] *** Quits: Nemo157 (nemo157@moz-n8c.b85.166.46.IP) (Ping timeout: 121 seconds) [15:46:49] *** Joins: _Vi (vi@moz-bbs.vhj.131.104.IP) [15:46:59] *** Quits: liquidmetal (liquidmetal@moz-u78kqf.fios.verizon.net) (Ping timeout: 121 seconds) [15:47:09] *** Joins: Nemo157 (nemo157@moz-19ra4p.dyn.nltelcom.net) [15:47:22] *** Quits: sgflt (sgflt@moz-b7jm2s.dip0.t-ipconnect.de) (Ping timeout: 121 seconds) [15:47:52] *** Quits: brianloveswords (brianlovesw@moz-bvav7m.fios.verizon.net) (Quit: My Mac has gone to sleep. ZZZzzz…) [15:47:53] *** Quits: latk (textual@moz-rlonfv.cam.ac.uk) (Quit: My Mac has gone to sleep. ZZZzzz…) [15:47:58] *** Joins: latk (textual@moz-rlonfv.cam.ac.uk) [15:48:56] *** Joins: ziad (ziad@moz-s65gmp.ca.comcast.net) [15:49:28] *** Quits: anjumkaiser (anjumkaiser@moz-fk3.apv.50.39.IP) (Ping timeout: 121 seconds) [15:52:11] *** Joins: ParadoxSpiral (ParadoxSpir@moz-abonc1.dip0.t-ipconnect.de) [15:52:24] *** Quits: lnostdal__ (lnostdal@moz-96hmj7.dsl.telepac.pt) (Ping timeout: 121 seconds) [15:54:40] *** Quits: log0ymxm (log0ymxm@moz-34f99v.slkc.qwest.net) (Connection closed) [15:54:41] *** Joins: mindtree (Mitch@moz-1auvn6.iprimus.net.au) [15:54:42] *** Joins: annodomini_ (lambda@moz-qgii5v.ma.comcast.net) [15:55:23] *** Joins: lnostdal__ (lnostdal@moz-96hmj7.dsl.telepac.pt) [15:55:35] *** Quits: annodomini (lambda@moz-qgii5v.ma.comcast.net) (Ping timeout: 121 seconds) [15:55:36] *** annodomini_ is now known as annodomini [15:55:41] *** Quits: chriskrycho (chriskrycho@moz-rv50s0.res.rr.com) (Ping timeout: 121 seconds) [15:55:55] *** Quits: chc4 (chc4@moz-jp1i28.biz.rr.com) (Ping timeout: 121 seconds) [15:56:44] *** Quits: sirGusWrk (Gustav@moz-bo7slh.sme.bredbandsbolaget.se) (Ping timeout: 121 seconds) [15:57:51] *** Joins: chriskrycho (chriskrycho@moz-rv50s0.res.rr.com) [15:58:13] What's the issue with line 6 here? http://is.gd/k9L8By [15:58:41] I.e., `use`ing std::f64 and calling f64::abs() is fine, but std::f64::abs is not. [15:59:25] *** Quits: Nilabhra (nilabhra@moz-d83.2g6.242.103.IP) (Connection closed) [15:59:43] *** Joins: lucian_ (lucian@moz-n1l.htl.74.194.IP) [16:00:05] *** Joins: meh (meh@moz-4v5.n5d.42.151.IP) [16:01:00] *** Quits: romanlevin (romanlevin@moz-jhq.qet.40.164.IP) (Connection closed) [16:01:30] *** Joins: panicbit2 (panicbit@moz-ob1844.dip0.t-ipconnect.de) [16:02:24] *** Quits: lucian (lucian@moz-iuo.htl.74.194.IP) (Ping timeout: 121 seconds) [16:02:54] *** Joins: mitaa (mitaa@moz-36dqvp.dyn.drei.com) [16:03:33] *** Quits: vadix_ (vadix@moz-ogk666.li8q.e9lr.b400.2607.IP) (Ping timeout: 121 seconds) [16:03:45] *** Quits: lucian_ (lucian@moz-n1l.htl.74.194.IP) (Ping timeout: 121 seconds) [16:04:00] *** esawin|pto is now known as esawin [16:04:00] *** Quits: panicbit (panicbit@moz-5pdkvo.dip0.t-ipconnect.de) (Ping timeout: 121 seconds) [16:04:53] *** Joins: lucian (lucian@moz-n1l.htl.74.194.IP) [16:05:28] the `use` line is a red herring [16:05:41] there is no std::f64::abs, only f64::abs (static method on type f64) [16:05:59] *** Joins: jviereck (Adium@moz-e719ch.dip0.t-ipconnect.de) [16:06:31] *** Joins: tennix (vagrant@moz-k4r.hki.243.114.IP) [16:07:55] *** Joins: alexherbo2 (alex@moz-c85.bha.255.109.IP) [16:07:55] *** Joins: chc4 (chc4@moz-jp1i28.biz.rr.com) [16:08:33] bluss: Wow [16:08:35] *** Joins: LambdaComplex (adam@moz-76u5ge.nc.charter.com) [16:08:42] I guess I tricked myself here. [16:09:01] *** Joins: julienXX (julienXX@moz-vrdhjo.abo.wanadoo.fr) [16:09:08] *** Quits: jgallagher (john@moz-72l538.ga.comcast.net) (Client exited) [16:09:10] std::f64's only job is to confuse [16:09:50] bluss: how so? [16:09:52] Do we really need both std::f64 and f64:: other than backcompat? [16:10:20] *** Quits: fl3 (fl3@moz-ghm.6bs.172.109.IP) (Connection closed) [16:10:24] SneakySnake: Sometimes this must be enough of a reason. ^^ [16:11:02] LambdaComplex: it's unfortunate that the module and this std::f64 confusion exists [16:11:12] maybe it can be solved once associated constants are stable [16:11:16] *** Quits: julienXX_ (julienXX@moz-vrdhjo.abo.wanadoo.fr) (Ping timeout: 121 seconds) [16:12:36] *** Quits: retropikzel (retropikzel@moz-8pe5l2.elisa-mobile.fi) (Quit: Leaving) [16:12:42] *** Joins: dwins (dwins@moz-9kg4ko.va.comcast.net) [16:12:55] *** Joins: sgflt (sgflt@moz-b7jm2s.dip0.t-ipconnect.de) [16:13:17] *** Joins: happy-dude_ (uid62780@moz-ljci7f.richmond.irccloud.com) [16:14:51] *** Quits: sgflt (sgflt@moz-b7jm2s.dip0.t-ipconnect.de) (Client exited) [16:15:04] *** Quits: EsBe (EsBe@moz-j68r7f.res.rr.com) (Ping timeout: 121 seconds) [16:15:24] *** Joins: Lilly (Lilly@moz-9k59ig.bredband.comhem.se) [16:17:21] *** Quits: annodomini (lambda@moz-qgii5v.ma.comcast.net) (Client exited) [16:17:22] *** Quits: stephanbuys (Adium@moz-p5kb8o.afrihost.co.za) (Quit: Leaving.) [16:18:41] *** Ms2ger|mtg is now known as Ms2ger [16:19:00] *** Quits: chriskrycho (chriskrycho@moz-rv50s0.res.rr.com) (Ping timeout: 121 seconds) [16:19:17] *** Quits: deadc0de (chsitter@moz-lrh.035.31.94.IP) (Ping timeout: 121 seconds) [16:19:29] bluss: Afteeeer discovering zip_mut_with thanks to your hint I don't think axpy is necessary. [16:19:43] (^ way too many eeee) [16:20:14] *** Quits: jimb (user@moz-6gkikn.or.comcast.net) (Ping timeout: 121 seconds) [16:20:40] interesting that you think so. Got feedback from another user who also thought this generic zip was a better interface than a specific method for it [16:20:58] Absolutely! [16:21:05] *** Joins: raze (raze@moz-uaf3to.members.linode.com) [16:21:07] since .zip_mut_with covers not just multiply-add but all other combinations [16:21:09] *** Joins: Gamecubic (cubic@moz-bglmk5.mc.videotron.ca) [16:21:26] *** Quits: goyox86 (textual@moz-qfs.570.70.83.IP) (Quit: My Mac has gone to sleep. ZZZzzz…) [16:21:35] A user finding zip_mut_with and some hypothetical axpy would immediately be confused and wonder why to use one over the other. [16:21:38] *** Joins: zrneely (zrneely@moz-87ud38.dyn.MIT.EDU) [16:21:57] *** Quits: samx (sami@moz-oq8dni.dyn.optonline.net) (Quit: My Mac has gone to sleep. ZZZzzz…) [16:22:02] *** Joins: musiKk (foobar@moz-ecd8ku.pools.vodafone-ip.de) [16:22:16] A generalized zip_mut_with_n in the form of a macro would be nice, but rust macros would need to expand a lot to allow for that. [16:22:24] there is a chance that I'll have to add this, just so that axpy from blas can be used [16:22:43] *** Quits: mgottschlag (quassel@moz-ffd4vr.qiv1.bbcb.1398.2a00.IP) (Ping timeout: 121 seconds) [16:22:45] *** Joins: kev_ (kevin_@moz-aa1.cd6.186.95.IP) [16:22:48] *** Joins: chriskrycho (chriskrycho@moz-rv50s0.res.rr.com) [16:22:55] *** Quits: eap_ (eap@moz-chsqii.tpgi.com.au) (Ping timeout: 121 seconds) [16:23:08] SuperFluffy: to which n have you used this. 3? [16:23:10] just wondering [16:23:14] all of them [16:23:19] hehe ok [16:23:25] I am not kidding. :D I even added one [16:23:35] *** Joins: fmendez (fmendez@moz-fts.urc.101.148.IP) [16:23:49] I tried to write a macro first, then I went for the macro that generates a function [16:23:57] I'm not sure how to sanely write it as a macro [16:24:09] *** Joins: demilux (demilux@moz-73qa6c.wa.comcast.net) [16:24:14] *** Quits: Gabriel_7 (Gabriel@moz-po3t0n.loria.fr) (Connection closed) [16:24:17] *** Joins: lnostdal_ (lnostdal@moz-vqklpq.dsl.telepac.pt) [16:24:43] I don't think you can really. Unless you allow for a:ident,A:expr,b:ident,B:expr,c:ident,C:expr,.... and so on. [16:25:09] *** Joins: deadc0de (chsitter@moz-lrh.035.31.94.IP) [16:25:12] *** Quits: gleb (gleb@moz-3ir1e8.rusanovka-net.kiev.ua) (Ping timeout: 121 seconds) [16:25:38] *** Quits: Aaronepower (Thunderbird@moz-sgf.dch.101.89.IP) (Client exited) [16:26:28] *** Quits: deadc0de (chsitter@moz-lrh.035.31.94.IP) (Quit: leaving) [16:26:52] *** Quits: lnostdal__ (lnostdal@moz-96hmj7.dsl.telepac.pt) (Ping timeout: 121 seconds) [16:27:42] Hm, no; I am not sure if my thought process there is correct. Nevermind [16:29:16] *** Joins: sgiles (sid26748@moz-q9vcpd.highgate.irccloud.com) [16:30:58] *** Joins: liquidmetal (liquidmetal@moz-28ie7g.cc.cmu.edu) [16:31:00] *** Quits: dinfuehr (dinfuehr@moz-1v6.2no.31.85.IP) (Connection closed) [16:31:06] *** Joins: brianloveswords (brianlovesw@moz-n4t7m6.biz.rr.com) [16:36:19] *** Joins: cruor99_ (cruor@moz-0os33h.customer.cdi.no) [16:36:19] *** Joins: cimes (cimes@moz-9e6.16c.135.128.IP) [16:36:49] *** Joins: vadix_ (vadix@moz-a8bn14.ff29.71g9.b400.2607.IP) [16:39:41] *** Joins: brianlov_ (brianlovesw@moz-n4t7m6.biz.rr.com) [16:39:41] *** Quits: brianloveswords (brianlovesw@moz-n4t7m6.biz.rr.com) (Connection closed) [16:41:49] *** Joins: goyox86 (textual@moz-qfs.570.70.83.IP) [16:41:49] *** Quits: brianlov_ (brianlovesw@moz-n4t7m6.biz.rr.com) (Connection closed) [16:42:02] *** Joins: ambaxter (ambaxter@moz-n7f.m5v.202.74.IP) [16:42:13] *** Quits: Lilly (Lilly@moz-9k59ig.bredband.comhem.se) (Quit: bajs) [16:42:41] *** Joins: cruor99 (cruor99@moz-0os33h.customer.cdi.no) [16:43:03] *** Quits: djcb (user@moz-ptk.tnt.157.194.IP) (Connection closed) [16:43:33] *** Joins: jgallagher (john@moz-d5e8oc.hfc.comcastbusiness.net) [16:44:12] *** Joins: log0ymxm (log0ymxm@moz-34f99v.slkc.qwest.net) [16:45:07] *** Quits: chriskrycho (chriskrycho@moz-rv50s0.res.rr.com) (Quit: My Mac has gone to sleep. ZZZzzz…) [16:45:44] *** Quits: mindtree (Mitch@moz-1auvn6.iprimus.net.au) (Ping timeout: 121 seconds) [16:46:33] *** Quits: ebel (rory@moz-l1ldq7.hsi4.kabel-badenwuerttemberg.de) (Connection closed) [16:48:14] *** Quits: log0ymxm (log0ymxm@moz-34f99v.slkc.qwest.net) (Ping timeout: 121 seconds) [16:49:00] *** Joins: brainproxy (michael@moz-k64.qtg.207.24.IP) [16:49:08] *** Quits: blank_name1 (blank_name@moz-349.ssl.183.192.IP) (Ping timeout: 121 seconds) [16:49:51] *** Joins: mindtree (Mitch@moz-o0ssp2.iprimus.net.au) [16:50:31] *** Quits: qwerty_nor (Thunderbird@moz-ar2hmo.adsl.cyfra.net) (Ping timeout: 121 seconds) [16:50:50] *** Quits: latk (textual@moz-rlonfv.cam.ac.uk) (Quit: My Mac has gone to sleep. ZZZzzz…) [16:50:51] *** zz_NameNotFound is now known as NameNotFound [16:51:04] *** Joins: euc (Erik@moz-u0d91k.dhcp.as2116.net) [16:51:20] *** Quits: fmendez (fmendez@moz-fts.urc.101.148.IP) (Quit: ) [16:51:51] <_habnabit> it's neat when i figure out what an issue is as i'm writing up a description of it [16:52:35] *** Joins: mib_4ay0lr (Mibbit@moz-d35klc.CS.McGill.CA) [16:53:04] *** Joins: gleb (gleb@moz-3ir1e8.rusanovka-net.kiev.ua) [16:53:14] Stupid question: when I started rust macros were unstable. Now I see that the macro section in the book is with the stable stuff... Did macros became stable when I was not looking? [16:53:42] mib_4ay0lr: depends how far ago that was [16:54:09] mib_4ay0lr: but there are two kinds of macros: regular substitution macros, and procedural macros, aka computer plugins [16:54:09] <_habnabit> macros have been stable since i started using rust, which was around 1.0 [16:54:38] regular macros were there for 1.0, computer plugins are still very unstable [16:54:41] *** Joins: rubdos (rubdos@moz-l7lf2c.access.telenet.be) [16:54:48] <_habnabit> (compiler plugins?) [16:54:56] Oh... I was probably mixing the two then... [16:55:03] Good to know, thank you :) [16:55:13] *** Joins: keeper (keeper@moz-ugb.sk0.231.216.IP) [16:55:36] Havvy: https://doc.rust-lang.org/book/compiler-plugins.html [16:55:41] computer. pffff [16:55:41] *** Quits: chc4 (chc4@moz-jp1i28.biz.rr.com) (Ping timeout: 121 seconds) [16:55:42] sorry [16:55:44] it's friday [16:56:32] and that was directed at _habnabit, not Havvy [16:56:35] *** Joins: viny (viny@moz-r0c4u5.hsi06.unitymediagroup.de) [16:57:08] *** Joins: brianloveswords (brianlovesw@moz-n4t7m6.biz.rr.com) [16:58:34] *** Quits: vmx (vmx@moz-hev71m.dip0.t-ipconnect.de) (Quit: Leaving) [16:59:09] *** Quits: brianloveswords (brianlovesw@moz-n4t7m6.biz.rr.com) (Connection closed) [17:00:02] *** Joins: brianloveswords (brianlovesw@moz-n4t7m6.biz.rr.com) [17:00:21] *** NameNotFound is now known as zz_NameNotFound [17:01:04] *** Joins: tycoon177 (Odoyle_@moz-ib495f.client.mchsi.com) [17:03:09] *** Joins: blank (blank@moz-v0medr.mpls.qwest.net) [17:04:35] *** Quits: starblue (juergen@moz-bao27l.pools.vodafone-ip.de) (Ping timeout: 121 seconds) [17:04:53] *** Joins: ubsan_ (ubsan@moz-92sbjt.wa.comcast.net) [17:07:10] <_habnabit> http://is.gd/Wy07Gh what implementation would conflict with this one...? do tuples already have Into? [17:07:44] *** Quits: Nemo157 (nemo157@moz-19ra4p.dyn.nltelcom.net) (Ping timeout: 121 seconds) [17:07:52] *** Quits: cruor99 (cruor99@moz-0os33h.customer.cdi.no) (Connection closed) [17:07:52] *** Quits: jkonecny (jkonecny@moz-vs8vb1.redhat.com) (Quit: Leaving) [17:07:56] *** Joins: cruor99 (cruor99@moz-0os33h.customer.cdi.no) [17:08:28] there's a blanket impl for Into that uses `From` [17:08:43] <_habnabit> is there a From for tuples? [17:09:02] every type has T: From [17:09:08] *** Joins: Fishrock123 (Fishrock123@moz-5igk34.dsl.bell.ca) [17:09:40] not sure if there is any way to make this work, let's turn it around and try from though [17:09:53] <_habnabit> i didn't think it was possible to do this using From [17:10:19] <_habnabit> since it would have to be From> for A, and neither From nor A are implemented in this crate [17:10:29] *** Joins: Nemo157 (nemo157@moz-jva.78t.166.46.IP) [17:10:31] *** Joins: samx (sami@moz-oq8dni.dyn.optonline.net) [17:10:33] not possible http://is.gd/oeGV44 [17:10:45] *** Joins: bur_sangjun (bur_sangjun@moz-m669ot.range165-120.btcentralplus.com) [17:10:46] yes you are right about that [17:11:04] *** Quits: yuja (yuja@moz-fkgj36.so-net.ne.jp) (Quit: Leaving) [17:11:18] Where am I going wrong http://is.gd/bMsUuC [17:11:38] <_habnabit> so what's the conflicting implementation...? [17:11:39] *** Joins: ubsan__ (ubsan@moz-92sbjt.wa.comcast.net) [17:11:42] *** Quits: jdm (jdm@moz-mu9.06r.98.75.IP) (Quit: ) [17:11:57] *** Joins: latk (textual@moz-rlonfv.cam.ac.uk) [17:12:06] <_habnabit> bur_sangjun, haha this looks like the same problem i'm having [17:12:20] *** Joins: log0ymxm (log0ymxm@moz-lro.cl4.60.66.IP) [17:12:32] _habnabit: I think it must be this one http://doc.rust-lang.org/nightly/src/core/up/src/libcore/convert.rs.html#205-212 [17:12:36] try implementing From instead [17:12:52] Doesn't work either [17:12:54] * Ms2ger tries [17:12:56] tried [17:13:16] damn, just reading back through the logs now [17:13:42] so From didn't work out for bur_sangjun's example? [17:14:04] The general advice is to implement From (and let the Into impl come automatically) [17:14:28] *** Quits: jviereck (Adium@moz-e719ch.dip0.t-ipconnect.de) (Quit: Leaving.) [17:14:36] *** Quits: boblehest (jlode@moz-c7qhnf.customer.lyse.net) (Connection closed) [17:14:40] http://is.gd/MDONid [17:14:42] Works with From [17:14:54] <_habnabit> hm [17:14:55] great [17:14:57] though need to add a Copy constraint [17:15:05] because array moves [17:15:07] *** Joins: nhirata_ (nhirata_@moz-5b2rpj.ca.comcast.net) [17:15:27] *** Quits: log0ymxm (log0ymxm@moz-lro.cl4.60.66.IP) (Connection closed) [17:15:31] *** Quits: lucian (lucian@moz-n1l.htl.74.194.IP) (A TLS packet with unexpected length was received.) [17:15:36] hmm Copy shouldn't strictly be needed [17:15:49] *** Quits: ubsan__ (ubsan@moz-92sbjt.wa.comcast.net) (Ping timeout: 121 seconds) [17:15:50] *** Joins: log0ymxm (log0ymxm@moz-lro.cl4.60.66.IP) [17:15:52] *** Quits: brianloveswords (brianlovesw@moz-n4t7m6.biz.rr.com) (Connection closed) [17:16:02] surely there's a way around that without slice patterns [17:16:38] bluss: Not that I can think of, I don't know of a way to say "I'm moving everything in the array so move the whole thing" like that [17:16:49] *** Joins: boblehest (jlode@moz-c7qhnf.customer.lyse.net) [17:16:54] <_habnabit> yeah ugh i guess i just straight up can't use From for mine [17:17:07] *** Joins: rkruppe (chatzilla@moz-7basqp.p5eo.1gvm.41b8.2001.IP) [17:17:26] *** Quits: SuperFluffy (janis@moz-19346r.physik.uni-potsdam.de) (Quit: WeeChat 1.4) [17:17:30] *** Joins: mgottschlag (quassel@moz-fd9i0e.hsi6.kabel-badenwuerttemberg.de) [17:17:31] even slice patterns don't implement this properly (wut) [17:17:36] *** Joins: lucian (lucian@moz-n1l.htl.74.194.IP) [17:18:03] Having some problems with mutable borrow. The borrow scope doesn't end where I'd expect it to. Any ideas? http://is.gd/ZlCkqo [17:18:22] bur_sangjun: I guess it's not a major restriction for your code (the Copy bound) [17:18:24] *** Quits: lucian (lucian@moz-n1l.htl.74.194.IP) (A TLS packet with unexpected length was received.) [17:18:27] *** Joins: lucian (lucian@moz-n1l.htl.74.194.IP) [17:18:31] *** Joins: dzbarsky (Adium@moz-qclv9b.82pc.j76f.0646.2601.IP) [17:18:33] *** Joins: SiegeLord (sl@moz-s8hpnn.ca.comcast.net) [17:18:45] bluss: Not really, though would be nice to be rid of it one day [17:18:46] *** Quits: lucian (lucian@moz-n1l.htl.74.194.IP) (A TLS packet with unexpected length was received.) [17:18:56] is there a method std that attempts to turn a Vec into a [T, n]? [17:18:58] *** Joins: GeneralAltoids (GeneralAlto@moz-5g5.tco.159.98.IP) [17:19:07] *** Joins: lucian (lucian@moz-iuo.htl.74.194.IP) [17:19:08] bluss: When we get specificity I should be able to add a competing one with clone, for instances where there is no copy [17:19:20] bluss: s/specificity/specialization/ forgot the term [17:19:35] Perceptes, no [17:19:40] <_habnabit> bluss, i'm just not sure how that impl you linked would be used here, since it has the type bound which (afaict) doesn't apply [17:20:00] *** Joins: anjumkaiser (anjumkaiser@moz-fk3.apv.50.39.IP) [17:20:10] bur_sangjun: why not use Clone directly then? [17:20:17] Ms2ger thank you [17:20:28] _habnabit: their parameter U is your A [17:20:29] bluss: I guess, clone mimics copy exactly on things with copy right? (by default, in stdlib) [17:20:47] _habnabit: wait, that's a false start [17:20:48] <_habnabit> bluss, but which From is it using, then? [17:20:51] bur_sangjun: yes [17:20:54] Perceptes, would be nice to have, but it's impossible to implement generically right now [17:21:12] http://is.gd/AP2Gpb as a solution then [17:21:12] _habnabit: it doesn't matter if it can't find a specific from -- it can't prove there is not a conflicting impl somewhere [17:21:19] <_habnabit> bluss, oh :( [17:21:25] bur_sangjun: You should be able to solve it by moving out of the array [17:21:37] no copy, no clone though. [17:21:39] <_habnabit> bluss, so it doesn't matter if the type bound doesn't match. bleh [17:21:39] *** Joins: brianloveswords (brianlovesw@moz-n4t7m6.biz.rr.com) [17:22:01] bluss: Yeah, in an ideal world there would be no copy or clone, but I can't think of a way to do that [17:22:21] _habnabit: I think their U is your A is correct [17:22:21] *** Joins: doener (doener@moz-fnh.n4j.147.5.IP) [17:22:44] *** Joins: lutter1 (lutter@moz-7v7ueu.PUBLIC.monkeybrains.net) [17:22:47] needs a `where A: !From>` [17:22:52] *** Quits: wldcordeiro (wldcordeiro@moz-ul1rm9.ut.comcast.net) (Ping timeout: 121 seconds) [17:22:59] _habnabit: and there is no telling if your A implements From or not [17:23:01] <_habnabit> is this why e.g. Result doesn't have a From? [17:23:17] nm. I'm a moron [17:24:01] _habnabit: I don't know. Maybe it's not a good idea [17:24:07] I believe that "Don't add From impls if you don't think they make for good argument conversions." [17:24:18] From everywhere doesn't really help anyone [17:24:23] *** Quits: brianloveswords (brianlovesw@moz-n4t7m6.biz.rr.com) (Connection closed) [17:24:44] <_habnabit> my use case is that i have a tuple struct that wraps something, and i was trying to figure out how to unwrap it [17:24:57] <_habnabit> Into seemed like a good choice [17:25:02] *** Quits: ambaxter (ambaxter@moz-n7f.m5v.202.74.IP) (Quit: ) [17:25:10] *** Quits: dzbarsky (Adium@moz-qclv9b.82pc.j76f.0646.2601.IP) (Ping timeout: 121 seconds) [17:25:16] I think it's nonsensical. Into is an argument conversion trait [17:25:16] *** Joins: Douman (Douman@moz-elh3s6.dynamic.mts-nn.ru) [17:25:20] *** Quits: iceiceice (chris@moz-n3v1ju.ias.edu) (Ping timeout: 121 seconds) [17:25:26] my example is https://internals.rust-lang.org/t/pre-rfc-impl-from-bool-for-i32-and-impl-from-i32-for-bool/3168/2 [17:25:41] so if you have an api like this: fn foo>(temperature: T) { } [17:25:55] should that silently accept T2 as a temperature? [17:26:02] since it can be Into-ed [17:26:40] <_habnabit> yes, because in my real code, it's approximately struct T2(A, PhantomData) [17:26:45] it turns into nonsense if these impls are stretched far outside the intent of the trait [17:27:05] <_habnabit> the A is the only actual value [17:27:07] *** Joins: durka42 (durka42@moz-d15k7q.pa.comcast.net) [17:27:10] hm ok, that sounds good [17:27:18] so then you pass the argument conversion test [17:27:43] *** Joins: rkruppe_ (chatzilla@moz-7basqp.p5eo.1gvm.41b8.2001.IP) [17:28:05] *** Quits: anjumkaiser (anjumkaiser@moz-fk3.apv.50.39.IP) (Ping timeout: 121 seconds) [17:28:05] *** Quits: JanC (janc@moz-638amg.dsl.scarlet.be) (Ping timeout: 121 seconds) [17:28:07] *** Quits: rkruppe_ (chatzilla@moz-7basqp.p5eo.1gvm.41b8.2001.IP) (Quit: ChatZilla 0.9.92 [Firefox 44.0.2/20160210153822]) [17:29:09] bluss: if you can formalize your rules I'll write a lint to lint bad From/Into impls [17:30:00] *** Quits: rkruppe (chatzilla@moz-7basqp.p5eo.1gvm.41b8.2001.IP) (Ping timeout: 121 seconds) [17:30:46] *** Joins: arjun_ (arjun@moz-isl.hij.60.27.IP) [17:31:21] *** Joins: skade (skade@moz-jjth55.pools.vodafone-ip.de) [17:31:21] *** Joins: dinfuehr (dinfuehr@moz-1v6.2no.31.85.IP) [17:31:33] oli_obk_: I'm not sure I can [17:32:04] bluss: maybe just a subset that's definitely bad, like forgetting a field [17:32:09] *** Joins: stephanbuys (Adium@moz-47rfs7.telkomadsl.co.za) [17:32:19] *** Quits: gleb (gleb@moz-3ir1e8.rusanovka-net.kiev.ua) (Ping timeout: 121 seconds) [17:32:28] *** Joins: est31 (quassel@moz-eol9ut.clients.your-server.de) [17:32:33] it's easier to say for the use of Into, AsRef, AsMut https://github.com/rust-lang/rust/issues/29701 [17:32:37] *** Quits: Alek (textual@moz-hivpjb.bb.online.no) (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) [17:32:50] since the recommendation there is to use them for argument conversion, not for say generic data structures [17:33:08] *** Quits: SiegeLord (sl@moz-s8hpnn.ca.comcast.net) (Quit: It's a joke, it's all a joke.) [17:33:22] <_habnabit> maybe it doesn't make sense for me, then [17:33:24] good: fn foo>() dubious: struct Foo> { } [17:33:31] <_habnabit> i can just make it (pub A, PhantomData) [17:33:55] *** Joins: jdm (jdm@66.207.193.21) [17:33:55] *** ChanServ sets mode: +o jdm [17:34:23] *** Quits: jvolkman (jvolkman@moz-71c3e8.r25b.sp7f.0000.2620.IP) (Ping timeout: 121 seconds) [17:34:23] bluss: that's already a good thing to lint against, I'll see what I can do [17:35:10] *** Quits: demilux (demilux@moz-73qa6c.wa.comcast.net) (A TLS packet with unexpected length was received.) [17:35:21] bluss: Yeah, in an ideal world there would be no copy or clone, but I can't think of a way to do that [17:35:24] *** Quits: dinfuehr (dinfuehr@moz-1v6.2no.31.85.IP) (Ping timeout: 121 seconds) [17:35:28] *** Quits: bur_sangjun (bur_sangjun@moz-m669ot.range165-120.btcentralplus.com) (Quit: Leaving) [17:35:41] *** Joins: kazagistar (Adium@moz-3iu.rs2.191.76.IP) [17:36:02] *** Joins: wldcordeiro (wldcordeiro@moz-ul1rm9.ut.comcast.net) [17:36:23] *** Quits: arjun_ (arjun@moz-isl.hij.60.27.IP) (Ping timeout: 121 seconds) [17:36:31] *** Joins: ubsan__ (ubsan@moz-92sbjt.wa.comcast.net) [17:36:36] *** Joins: bur_sangjun (bur_sangjun@moz-m669ot.range165-120.btcentralplus.com) [17:36:49] *** Quits: liquidmetal (liquidmetal@moz-28ie7g.cc.cmu.edu) (Ping timeout: 121 seconds) [17:36:51] *** Quits: ubsan__ (ubsan@moz-92sbjt.wa.comcast.net) (Quit: ) [17:37:06] is the best way to do `Option> -> Option` `option.unwrap_or_else(None)` or is there something more idiomatic? [17:37:23] *** Quits: cruor99 (cruor99@moz-0os33h.customer.cdi.no) (Connection closed) [17:37:58] *** Joins: nikkibee (quassel@moz-0d608l.ipv6.telus.net) [17:38:24] bur_sangjun: this is "obviously" safe http://is.gd/qbxlbd [17:38:31] just a bit strange that there is no safe way to move out [17:38:33] *** Quits: ParadoxSpiral (ParadoxSpir@moz-abonc1.dip0.t-ipconnect.de) (Quit: cya) [17:38:35] *** Joins: brianloveswords (brianlovesw@moz-n4t7m6.biz.rr.com) [17:38:38] bur_sangjun: using .and_then maybe? [17:39:19] bluss: I'm using `Vec::get` on `Vec>`, hence it gives out Option> [17:39:37] There's unwrap_or_default() [17:39:38] bluss: As for the obviously safe, I'd rather keep my code free of unsafe code for now, even though I agree with you that it's safe [17:39:43] *** Joins: ubsan__ (ubsan@moz-6vsc6o.s3np.5mou.fb90.2607.IP) [17:39:48] bur_sangjun: sounds good to me [17:39:51] *** Joins: zacstewart (zacstewart@moz-qi6qci.ga.comcast.net) [17:39:54] There's also .and_then(|x| x) which kinda sucks [17:40:08] *** AutomatedTester|AFK is now known as AutomatedTester [17:40:19] *** Quits: oli_obk_ (smuxi@moz-um2.0sb.52.141.IP) (Connection closed) [17:40:54] Quick question about Cargo -- is it advisable to prefer `cargo update` over manually going into the Cargo.lock file and bumping versions up? [17:41:05] Yes [17:41:07] yes [17:41:09] don't edit Cargo.lock by hand [17:41:14] *** Joins: jvolkman (jvolkman@moz-pev9rv.r25b.sp7f.0000.2620.IP) [17:41:22] *** Joins: JanC (janc@moz-diemsm.dsl.scarlet.be) [17:41:30] You can use `cargo update -p crate_name --precise version` if you want full control over the results [17:41:34] *** Joins: arjun_ (arjun@moz-isl.hij.60.27.IP) [17:41:55] *** Quits: benbergman (ben@moz-8vm.01g.81.208.IP) (A TLS packet with unexpected length was received.) [17:41:57] Nifty! Thanks guys. [17:42:02] and you can downgrade using that command too [17:42:13] *** Quits: Ms2ger (Ms2ger@moz-hfkmvr.access.telenet.be) (Quit: nn) [17:42:21] Actually, what I want to do is `Option<&Option> -> &Option`, which is much harder by my initial tests [17:42:25] Tuples are irritatingly close to being a good substitute for bitflags - just add a way to unpack a u8 into an 8-tuple of booleans and allow slicing a tuple to get a smaller tuple. [17:42:41] *** Quits: brianloveswords (brianlovesw@moz-n4t7m6.biz.rr.com) (Ping timeout: 121 seconds) [17:42:43] *** Quits: laumann (thomas@moz-3m6.3kq.109.2.IP) (Ping timeout: 121 seconds) [17:42:46] make a custom trait for it? [17:42:57] *** Joins: housl (housl@moz-iqc.e3c.70.166.IP) [17:43:18] *** Quits: ubsan_ (ubsan@moz-92sbjt.wa.comcast.net) (Ping timeout: 121 seconds) [17:44:26] *** Joins: erickt (erickt@moz-qie.6p3.217.74.IP) [17:44:26] *** ChanServ sets mode: +ao erickt erickt [17:45:42] *** Quits: mkoskar (mkoskar@moz-f7r9kh.t7od.j6um.3b40.2a03.IP) (Client exited) [17:45:58] *** Quits: kev_ (kevin_@moz-aa1.cd6.186.95.IP) (Ping timeout: 121 seconds) [17:46:00] *** Quits: Quxxy2 (Quxxy@moz-efh10q.internode.on.net) (Ping timeout: 121 seconds) [17:46:06] Ketsuban: (bool, bool, bool, bool, bool, bool, bool, bool) isn't 1 byte [17:46:15] *** Joins: anjumkaiser (anjumkaiser@moz-26l.0t5.178.182.IP) [17:46:39] *** Quits: viny (viny@moz-r0c4u5.hsi06.unitymediagroup.de) (Quit: Verlassend) [17:47:00] Is there some way to reference a struct's field using a string variable? like, `var.field`. I suppose what I'm trying to do is get `var` to expand to its value before being used as the name of a struct [17:47:33] *** Quits: arjun_ (arjun@moz-isl.hij.60.27.IP) (Connection closed) [17:47:56] sfackler: True. I was thinking specifically about my usecase, where I want to match on the possible values of a >8-bit quantity. Using literals I have to add a _ => unreachable!() clause to satisfy the compiler because it doesn't know that the result of `value >> 11 & 0b1111` is constrained to four bits. [17:48:08] *** Joins: cruor99 (cruor99@moz-230so5.customer.cdi.no) [17:48:18] *`(value >> 11) & 0b1111` [17:48:19] LambdaComplex: Like in JavaScript-like languages where you could write either var["field"] or var.field? [17:48:25] *** Joins: brianloveswords (brianlovesw@moz-n4t7m6.biz.rr.com) [17:48:38] mbrubeck: No idea :P [17:48:59] rust doesn't really have runtime interpretation like that [17:49:01] LambdaComplex: That sort of thing won't work in general in Rust; things like variable names exist at compile time, not at runtime [17:49:23] *** Joins: rkruppe (chatzilla@moz-7basqp.p5eo.1gvm.41b8.2001.IP) [17:49:23] *** Quits: Nemo157 (nemo157@moz-jva.78t.166.46.IP) (Ping timeout: 121 seconds) [17:49:24] mbrubeck: So, should I just use match then? [17:49:25] *** Quits: Mermi (uid96745@moz-v9qrgi.richmond.irccloud.com) (Quit: Connection closed for inactivity) [17:49:55] *** Joins: AlisdairO (anonymous@moz-ntsaoe.cable.virginm.net) [17:49:57] *** Joins: skeet70 (skeet70@moz-evm.d9f.15.71.IP) [17:50:18] or a hash table... or use an enum or a reference instead of a string... depends on what you're trying to do. [17:50:57] *** Joins: mattrudder (textual@moz-l5tm8s.sntcca.sbcglobal.net) [17:51:38] *** zz_NameNotFound is now known as NameNotFound [17:52:18] *** Quits: anjumkaiser (anjumkaiser@moz-26l.0t5.178.182.IP) (Ping timeout: 121 seconds) [17:53:00] *** Joins: gleb (gleb@moz-3ir1e8.rusanovka-net.kiev.ua) [17:53:02] *** Joins: Alek (textual@moz-hivpjb.bb.online.no) [17:53:04] *** Joins: sirGusWrk (Gustav@moz-bo7slh.sme.bredbandsbolaget.se) [17:53:40] *** Quits: brianloveswords (brianlovesw@moz-n4t7m6.biz.rr.com) (Connection closed) [17:54:03] *** Joins: Mermi (uid96745@moz-v9qrgi.richmond.irccloud.com) [17:54:13] *** Joins: gleb_ (gleb@moz-3ir1e8.rusanovka-net.kiev.ua) [17:54:43] *** Quits: croyd (croyd@moz-3bf3hs.cable.rcn.com) (Connection closed) [17:55:08] *** Quits: TimNN (TimNN@moz-r8l.9ss.89.141.IP) (Quit: My Mac has gone to sleep. ZZZzzz…) [17:55:12] *** Joins: brianloveswords (brianlovesw@moz-n4t7m6.biz.rr.com) [17:55:34] *** Quits: miqid (miqid@moz-nq6js8.static.sl-reverse.com) (Ping timeout: 121 seconds) [17:56:07] *** Joins: robotblake (robotblake@moz-0v636k.wa.comcast.net) [17:56:21] LambdaComplex, maybe https://github.com/sfackler/rust-phf [17:57:11] *** Joins: polezaivsani (polezaivsan@moz-k35vmr.baltnet.ru) [17:57:29] *** Quits: gleb (gleb@moz-3ir1e8.rusanovka-net.kiev.ua) (Ping timeout: 121 seconds) [17:58:08] Can someone please explain what the difference between String and str and &'static str is? [17:58:13] *** Quits: brianloveswords (brianlovesw@moz-n4t7m6.biz.rr.com) (Connection closed) [17:58:15] Because I keep running into errors because I don't know the difference [17:58:41] LambdaComplex: a String is like a Vec, it's a growable, owned sequence of characters [17:58:50] &str is a borrowed view of a String which is owned by someone else [17:58:51] *** Quits: gleb_ (gleb@moz-3ir1e8.rusanovka-net.kiev.ua) (Ping timeout: 121 seconds) [17:59:02] And what about `str`? [17:59:13] And how do I figure out which one I'm supposed to be using? [17:59:21] the question is always "who owns this data" [17:59:22] *** Quits: latk (textual@moz-rlonfv.cam.ac.uk) (Quit: My Mac has gone to sleep. ZZZzzz…) [17:59:32] ajeffrey: reping! [17:59:37] *** Quits: seriyPS (seriy@moz-8fj.1a0.172.178.IP) (Quit: Leaving.) [17:59:51] *** Quits: zrneely (zrneely@moz-87ud38.dyn.MIT.EDU) (Ping timeout: 121 seconds) [17:59:54] erickt: repong! [18:00:04] 'str' isn't used directly, it means "a sequence of u8 interpreted as UTF-8 encoded characters" [18:00:20] ajeffrey: hey! I'm playing around with parsell, and, well, I need some help :) [18:00:27] but it doesn't say how _long_ the sequence is, which is why you always have it behind a fat pointer, &str, which has the length embedded in it [18:00:36] erickt: I'm not surprised, [18:00:42] iirc, String : &str as Vec : &[T] [18:00:43] right? [18:00:49] right [18:00:54] user-friendliness is not where I am at the moment :( [18:01:00] where owned : borrowed [18:01:00] ajeffrey: the type errors I get can be a tad... inscrutable [18:01:10] *** NameNotFound is now known as zz_NameNotFound [18:01:14] erickt: yes, this is annoying [18:01:50] LambdaComplex: and lastly &'static str is still a borrow, but one with the longest possible lifetime ('static), so you don't really have to worry about the lifetime. usually it is a borrow of a string that's stored in the program file itself [18:01:50] it's because the trait that implements all the helper methods doesn't know some of the types involved [18:02:11] ajeffrey: have you figured out any ways to make things a bit more clear? I've been trying to write a toy json parser [18:02:17] the Parser trait is the one that implements and_then, or_else etc. [18:02:31] *** Joins: brianloveswords (brianlovesw@moz-n4t7m6.biz.rr.com) [18:02:32] *** Quits: AlisdairO (anonymous@moz-ntsaoe.cable.virginm.net) (Client exited) [18:02:35] ajeffrey: yeah [18:02:38] and it can't be parameterized on the input or output types [18:03:07] since that leads to type inference failures :( [18:03:14] :( [18:03:23] durka42: is there something special about &[T] slices that makes them fat pointers compared to plain &T? [18:03:34] so you end up with type errors quite a lot later than you'd like [18:03:40] polezaivsani: yeah, they are really (*ptr, len) [18:03:40] polezaivsani: yes [18:03:44] *** Quits: ansible1 (kvirc@moz-ks4ued.co.comcast.net) (Ping timeout: 121 seconds) [18:03:45] do you have code I could look at? [18:03:49] polezaivsani: [T] (and str) are Dynamically Sized Types [18:03:55] ajeffrey: sure! [18:04:13] polezaivsani: so you can only have them behind a pointer, like &[T] or Box<[T]>, where the size can be stored in the pointer at runtime (because at compile time the size is not known) [18:04:13] polezaivsani: &[T] is a special case of &U (here U = [T]) [18:04:14] ajeffrey: it's terrible code: https://gist.github.com/erickt/d0cbaed7dddabb022b6b [18:04:25] *** Joins: sargas (sargas@moz-40ijd1.ut.comcast.net) [18:04:52] durka42: i see. last thing - what says str is DST, is there some makrer? [18:05:04] erickt: boy you've been busy! [18:05:08] *** Joins: jfo (jfo@moz-k3r.ebo.124.64.IP) [18:05:22] ajeffrey: :) long train ride without wifi [18:05:44] I... think the set of unsized types is basically hardcoded into the compiler [18:06:16] of course you can make new ones by wrapping the builtin ones [18:06:17] *** Quits: samx (sami@moz-oq8dni.dyn.optonline.net) (Quit: My Mac has gone to sleep. ZZZzzz…) [18:06:43] there is a marker trait, Sized, which you can check to see if a particular type is sized or not [18:06:51] erickt: which version of Parsell were you using? [18:07:01] ajeffrey: I think the latest one in cargo? [18:07:04] oh I forgot trait objects! when you use the name of a trait as a type, that is also dynamically sized [18:07:04] *** Joins: IanCormac84 (Nathan@moz-ja6.mia.214.206.IP) [18:07:09] like Box and &Trait [18:07:11] those are fat pointers [18:07:22] ajeffrey: which is 0.5.0 [18:07:38] durka42: i know, ive used the last one and prob wont qualify for an answer, but still - Box<[T]> who gets to store the length here? [18:07:43] OK, I'll test with that. [18:08:20] polezaivsani: check the size of Box<[T]>, there's room for a pointer and a length [18:08:54] durka42: thanks a ton! [18:09:34] *** Quits: brianloveswords (brianlovesw@moz-n4t7m6.biz.rr.com) (Quit: My Mac has gone to sleep. ZZZzzz…) [18:10:57] *** Joins: brianloveswords (brianlovesw@moz-n4t7m6.biz.rr.com) [18:11:19] *** Quits: chris_99 (chris_99@moz-g2jhk1.clients.your-server.de) (Ping timeout: 121 seconds) [18:11:30] *** Joins: croyd (croyd@moz-p58.284.10.129.IP) [18:11:40] *** Joins: demilux (demilux@moz-153.u1a.99.70.IP) [18:12:40] erickt: ok the problem is that when you write p.and_then(q), [18:12:50] q has to be a committed parser, [18:12:58] not just an uncommitted parser, [18:13:14] to make sure the parser is LL(1). [18:13:31] how do I do that? [18:13:59] *** Quits: jeffbradberry (jrb@moz-mrjdh9.rlghnc.sbcglobal.net) (Ping timeout: 121 seconds) [18:14:03] *** Quits: musiKk (foobar@moz-ecd8ku.pools.vodafone-ip.de) (Ping timeout: 121 seconds) [18:14:11] *** jdm is now known as jdm|f00ding [18:14:22] In the code "let parser = ValueParser.star(Vec::new).and_then(rbracket);" [18:14:38] you need rbracket to be Committed. [18:14:44] *** Joins: bkearns (Adium@moz-rudtng.static.wiline.com) [18:15:01] This is the difference between character(is_foo) (which is uncommitted, since it may backtrack) [18:15:08] But I'm scared of commitment [18:15:10] *rimshot [18:15:20] and CHARACTER (which is committed, since it doesn't backtrack). [18:15:24] ooooh [18:15:50] ooooh. [18:16:03] Static enforcement of LL(1) [18:16:51] you need something like rbracket.or_else(CHARACTER.map(whatever_error)). [18:17:04] *** Quits: skade (skade@moz-jjth55.pools.vodafone-ip.de) (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) [18:17:13] I didn't get that was the difference [18:17:16] so if I do `let var = "foo"`, what type is var? [18:17:28] *** Joins: latk (textual@moz-q2tvtg.cable.virginm.net) [18:17:32] you're probably going to want p.and_then_try(q) and friends, [18:17:44] to get errors to bubble properly. [18:17:52] *** Quits: vadix_ (vadix@moz-a8bn14.ff29.71g9.b400.2607.IP) (Ping timeout: 121 seconds) [18:18:07] LambdaComplex: &'static str [18:18:10] erickt: tht would be something to do with not actually having written documentation :( [18:18:13] ajeffrey: yeah I played with those too [18:18:26] durka42: What if i set it as mutable? [18:18:39] that doesn't affect the type at all [18:18:54] ajeffrey: probably should have read the full docs before playing with it. I'm just so used to reading the source [18:18:59] in my defence, I've rewritten the library so many times, any documentation would be horribly out of date by now [18:19:04] *** Quits: rkruppe (chatzilla@moz-7basqp.p5eo.1gvm.41b8.2001.IP) (Quit: ChatZilla 0.9.92 [Firefox 44.0.2/20160210153822]) [18:19:19] erickt: the source is probably the best documentation at the moment :( [18:20:00] erickt: the other issue you'll hit is that the type checker blows up very quickly, [18:20:15] *** Quits: scriptor (scriptor@moz-19q800.res.rr.com) (Connection closed) [18:20:35] *** Joins: scriptor (scriptor@moz-kp2cqq.h6np.s8u9.2000.2604.IP) [18:20:53] ajeffrey: Oh I saw that. I've seen some glorious error messages that were two plus pages of text for a single type [18:20:54] I managed to use 10G of memory typechecking a parser. [18:20:56] *** Quits: goyox86 (textual@moz-qfs.570.70.83.IP) (Quit: Textual IRC Client: www.textualapp.com) [18:21:00] https://github.com/rust-lang/rust/issues/31849 [18:21:15] erickt: yes, the type errors are a sight to behold. [18:21:31] wow [18:21:32] 10G [18:21:40] erickt: indeed. [18:21:50] I'm working on a fix [18:22:13] the issue is caused by the type-checker not caching associated types [18:22:18] *** Joins: lidavidm (lidavidm@moz-45t74f.cit.cornell.edu) [18:22:19] *** Joins: ShadowIce (pyoro@moz-d6d775.hsi.kabel-badenwuerttemberg.de) [18:22:29] so they end up being recalcuated ever time, and boom! [18:23:03] *** Quits: brianloveswords (brianlovesw@moz-n4t7m6.biz.rr.com) (Connection closed) [18:23:13] the fix requires changing what is an associated type vs what is a type parameter [18:23:29] *** Joins: jimb (user@moz-09a.i8g.126.207.IP) [18:23:30] *** Joins: brianloveswords (brianlovesw@moz-n4t7m6.biz.rr.com) [18:23:31] *** Joins: niconii (nicole@moz-af82ih.frgo.qwest.net) [18:23:31] *** ChanServ sets mode: +ao niconii niconii [18:23:35] so it impacts pretty much the whole library :( [18:23:52] :( [18:24:00] types are overrated [18:24:19] *** Quits: arBmind (Andreas@moz-6q36uk.dyn.telefonica.de) (Quit: Leaving.) [18:24:26] :) [18:24:29] *** Joins: ejpbruel (ejpbruel@moz-1r0f95.dynamic.ziggo.nl) [18:24:37] *** Quits: scriptor (scriptor@moz-kp2cqq.h6np.s8u9.2000.2604.IP) (Ping timeout: 121 seconds) [18:24:39] I'm not the only one hitting this problem: https://github.com/rust-lang/rust/issues/22204#issuecomment-149433123 [18:24:50] *** Joins: cite-reader (ahill@moz-pv1j2k.swbr.surewest.net) [18:24:55] Parsers are very good at killing typecheckers apparently. [18:25:05] i was wondering why rust doesnt allow struct inheritance [18:25:10] *** Quits: ubsan__ (ubsan@moz-6vsc6o.s3np.5mou.fb90.2607.IP) (Quit: <3) [18:25:16] *** Joins: ubsan_ (ubsan@moz-cc6.3fu.114.66.IP) [18:25:18] ^ yet [18:25:44] dikaoisune: how would you recommend working around the lack of struct inheritance for now? [18:25:45] *** Quits: brianloveswords (brianlovesw@moz-n4t7m6.biz.rr.com) (Connection closed) [18:25:56] so what's the problem you're trying to solve [18:26:03] *** Joins: brianloveswords (brianlovesw@moz-n4t7m6.biz.rr.com) [18:26:04] *** Joins: urcra (urcra@moz-9lk9gn.cpe.webspeed.dk) [18:26:13] b/c rust has many constructs to share code between types [18:26:25] and to allow heterogeneous data structures [18:26:31] two of the most common uses for inheritance [18:27:12] ajeffrey: as an alternative, a few months ago I was playing around with the pure snappy implementation: https://github.com/erickt/rust-snappy/blob/read2/src/decompress.rs [18:27:19] dikaiosune: well, suppose i find myself having two data structures, A and B, and B turns out having all the same fields as A + some extra [18:27:35] dikaiosune: that usually suggests that B should inherit from A, right? [18:27:41] ejpbruel: is there a reason that B can't just have an A in it it? [18:27:49] ajeffrey: I was doing a hand written parser that used a state machine to handle jumping in and out of a buffered reader [18:27:54] and use A's methods with some extra stuff on top? [18:28:03] *** Joins: gopar (gopar@moz-5039uj.ca.comcast.net) [18:28:16] dikaiosune: that could work, but then suppose A implements a number of traits. what would be an easy way to make B adopt all the traits from A? [18:28:26] do i simply have to forward everything to A? [18:28:41] *** Quits: ksad (ksad@moz-oi4ckg.cnt.nerim.net) (Connection closed) [18:28:46] *** Quits: shellac (pldms@moz-lngnj4.bris.ac.uk) (Quit: Ex-Chat) [18:28:48] ajeffrey: I was trying to replace some unsafe code in the upstream project that was saving the raw pointer to the buffer in order to handle the boundary case [18:28:51] you could [18:28:58] dikaiosune: so lets say A implements trait T, and I want B to implement T by forwarding to A [18:29:05] ejpbruel: it's what i've done so far, but i'm far from an expert on the "right" way to do traits [18:29:09] can i avoid having to write boilerplate code in which i forward everything to A? [18:29:29] ajeffrey: the pain of writing all this was the driving force for me writing stateful (https://erickt.github.io/blog/2016/01/27/stateful-in-progress-generators/) [18:29:35] ejpbruel: you can use Deref [18:29:38] ejpbruel: that's a very good question, and it's one that i would normally ask of the other nice people in this channel :) [18:29:38] *** Joins: chris_99 (chris_99@moz-g2jhk1.clients.your-server.de) [18:29:45] ^ [18:29:55] * ejpbruel reads up on Deref [18:30:02] erickt: that's pretty much the use case for parsell too.\ [18:30:07] ejpbruel: https://doc.rust-lang.org/book/deref-coercions.html [18:30:12] ajeffrey: do you have any opinion on if we had better language level support for state machines/generators would that help out with parsell? [18:30:19] Saving and restoring parser state at packet boundaries is a pain! [18:31:00] erickt: my experience with generators etc. in the language is they never quite line up with what you want, [18:31:10] durka42: oh, that looks very interesting! [18:31:19] *** Joins: gleb (gleb@moz-3ir1e8.rusanovka-net.kiev.ua) [18:31:28] e.g. the JS yield protocol is the one I played with, [18:31:38] durka42: so if I implement Deref for B, I can use it in any context where an A is expected? [18:31:48] and I always ended up just writing a library. [18:31:50] almost any context [18:32:05] ajeffrey: I'm unfamiliar with JS's yield protocol [18:32:06] ejpbruel: by treating B like a reference to A, and prefixing it with an * [18:32:20] erickt: the issue is things like backtracking / error propagation, [18:32:24] right except usually rust will insert that * for you automatically [18:32:29] *** Quits: sargas (sargas@moz-40ijd1.ut.comcast.net) (Quit: This computer has gone to sleep) [18:32:33] *** Joins: p32blo (p32blo@moz-gbnpoc.di.uminho.pt) [18:32:35] true [18:32:36] *** Joins: dinfuehr (dinfuehr@moz-1v6.2no.31.85.IP) [18:32:43] *** Joins: ZRM (ZRM@moz-66cm9g.range81-146.btcentralplus.com) [18:32:47] *** Joins: mmalone (mmalone@moz-adr.u03.49.209.IP) [18:32:53] durka42: right, so if i have a reference to B, I suppose I dont need the *? [18:32:59] yeah [18:33:10] awesome [18:33:37] ajeffrey: hm. yeah true. What about if you had coroutines, where you could interact with the coroutine while it's processing to say whether or not to commit to some state? [18:33:43] durka42: thanks for the quick answer! [18:34:17] erickt: I guess I'd look at it the other way round, [18:34:28] why is a syntax extension needed? [18:34:36] rather than a library. [18:34:43] *** Joins: sargas (sargas@moz-40ijd1.ut.comcast.net) [18:34:56] ajeffrey: because writing state machines by hand is annoying :) [18:35:03] the thing you can't do with a library is, e.g. program in direct style, [18:35:20] you end up writing foo.map(|x| bar) [18:35:34] rather than "let x = foo; bar;" [18:35:34] *** Joins: Nemo157 (nemo157@moz-sqm0o8.dyn.nltelcom.net) [18:35:38] which is much nicer [18:36:10] erickt: yes, but if you're okay with combinators, then you can hide the state machine. [18:36:20] yeah. I'm hoping that we could get to effectively `let x = foo; yield x; bar;` [18:36:28] I really ought to play more with combinators [18:36:33] the thing you can't hide is the combinators, [18:36:39] *** Quits: dinfuehr (dinfuehr@moz-1v6.2no.31.85.IP) (Ping timeout: 121 seconds) [18:36:45] if we can solve that pesky error message explosion problem [18:36:46] unless you have something like Haskell's do notation. [18:36:52] *** Quits: casey_ (casey@moz-v0ns05.tpgi.com.au) (Connection closed) [18:37:01] *** Joins: jincreator (jincreator@moz-mv2.45t.97.183.IP) [18:37:15] *** ahal is now known as ahal|afk [18:37:23] *** Quits: ZRM (ZRM@moz-66cm9g.range81-146.btcentralplus.com) (Client exited) [18:37:30] erickt: that's true, you can often get better type errors from language features than you can from a library. [18:37:47] *** Joins: casey_ (casey@moz-v0ns05.tpgi.com.au) [18:37:57] libraries are stuck with the type errors the language gives them, [18:38:16] *** Quits: brianloveswords (brianlovesw@moz-n4t7m6.biz.rr.com) (Ping timeout: 121 seconds) [18:38:18] unless you want to write custom static analyses [18:38:30] (e.g. lints or dependent types). [18:38:31] *** Joins: brianloveswords (brianlovesw@moz-n4t7m6.biz.rr.com) [18:38:32] *** Joins: cespare (cespare@moz-fc8h4f.compute-1.amazonaws.com) [18:41:36] *** Joins: pcwalton (pcwalton@moz-nh2.o1i.216.216.IP) [18:41:36] *** ChanServ sets mode: +ao pcwalton pcwalton [18:41:40] *** Joins: fyolnish (fyolnish@moz-8tfsb3.so-net.ne.jp) [18:41:49] *** Quits: casey_ (casey@moz-v0ns05.tpgi.com.au) (Ping timeout: 121 seconds) [18:42:37] *** Quits: pbor (paolo@moz-vfh.hnp.202.89.IP) (Connection closed) [18:43:32] *** Quits: Axord (axo@moz-7kd1sd.ca.charter.com) (Quit: What's the worst that could ha-) [18:44:35] Hmm... I am currently learning macros, and I found a singularity... the definition of stringify! match ($t:tt) and will accept `1 + 1` as argument. Creating my own macro matching ($t:tt) will complain on the same input with "no rules expected the token `+`... [18:44:40] *** Joins: Axord (axo@moz-7kd1sd.ca.charter.com) [18:45:14] *** Joins: arBmind (Andreas@moz-b51sut.adsl.alicedsl.de) [18:45:32] *** Quits: mstevens (mstevens@moz-itk2jg.etla.org) (Quit: leaving) [18:45:36] stringify! is a compiler builtin [18:45:53] *** Quits: cruor99 (cruor99@moz-230so5.customer.cdi.no) (Connection closed) [18:45:53] so the definition given in the API is a lie? :( [18:46:09] yeah it should probably be $($t:tt)* [18:46:11] so the docs are not necessarily to be trusted since the version you find there exists only so it shows up in the docs [18:46:46] Hmm... I see. [18:47:23] Well, I'll see if I am still able to spin off what I am trying to do: a macro wrapper around process::Command for easy scripting directly within rust... [18:47:54] 13_4__8__ 9_11__12_ 13_4__ 8_9__11_ 13_ 4_8_ 11__12_ 13_ 4_ [18:47:57] 4| 8_9__11| 12_ 13\4|_ 8_9| 11_ 12\ 4/ 8\\ 9\ 11/ 12/ 13| 4| 8| [18:48:00] 8| 9|_ 12| 13|_4) 8|| 9|11| 12| 13| 4|/ 8_ 9\11\ 12V 13/| 4| 8| 9| [18:48:03] 9| 11_12| 13| 4_ 8< 9| 11|12| 13|_4| 8/ 9__11_ 12\| 13| 4|8_|9_|11_| [18:48:06] 11|_12| 4|_8| 9\_11\_12__13|_4__8_/9_/ 12\13_\4_| 8(9_|11_|12_) [18:48:09] [18:48:11] *** Quits: sargas (sargas@moz-40ijd1.ut.comcast.net) (Quit: This computer has gone to sleep) [18:48:16] \o/ [18:48:20] hurrah [18:48:54] hi bascule [18:51:54] *** Quits: fyolnish (fyolnish@moz-8tfsb3.so-net.ne.jp) (Connection closed) [18:53:17] ohai [18:53:28] *** Quits: brianloveswords (brianlovesw@moz-n4t7m6.biz.rr.com) (Connection closed) [18:53:36] *** Quits: stelarcf_ (stelarcf@moz-3gh.lb8.81.92.IP) (Client exited) [18:53:42] *** Joins: stelarcf__ (stelarcf@moz-3gh.lb8.81.92.IP) [18:53:46] *** stelarcf__ is now known as stelarcf_ [18:54:04] *** Quits: ejpbruel (ejpbruel@moz-1r0f95.dynamic.ziggo.nl) (Ping timeout: 121 seconds) [18:54:04] *** Joins: brianloveswords (brianlovesw@moz-n4t7m6.biz.rr.com) [18:54:40] *** Joins: zrsmith92 (textual@moz-3m7krt.dyn.suddenlink.net) [18:55:23] *** Joins: untitaker_ (untitaker@moz-3mb12h.highway.telekom.at) [18:55:27] *** Joins: tillarnold (tillarnold@moz-hjsec5.ho1o.o6qc.1205.2a02.IP) [18:55:33] success [18:56:12] *** Quits: mmalone (mmalone@moz-adr.u03.49.209.IP) (Quit: My Mac has gone to sleep. ZZZzzz…) [18:56:13] *** Joins: bob_twinkles (bob_twinkle@moz-13lide.mphs.mm2e.b400.2607.IP) [18:56:18] *** jdm|f00ding is now known as jdm [18:57:11] !gh 30080 [18:57:11] [PR 30080] fix docs for compiler builtin macros [18:57:14] *** Quits: untitaker (untitaker@moz-j0899n.highway.telekom.at) (Ping timeout: 121 seconds) [18:57:14] *** untitaker_ is now known as untitaker [18:57:18] ^ I guess I need to do a followup to that for stringify!() [18:57:41] (and I still don't like the solution we ended up with there, pretending that cfg!() takes $($t:tt)*) [18:57:55] How do I convert an argument into an f64? [18:58:10] LambdaComplex: what type is the argument? [18:58:15] *** Joins: carols10cents (carols10cen@moz-ovg858.fios.verizon.net) [18:58:20] LambdaComplex: by 'an argument' do you mean 'an argument to the program' or 'an argument to a function' [18:58:28] steveklabnik: The former [18:58:34] two things [18:58:36] aha [18:58:38] so a string then [18:58:40] 1) you can use a library for function argument handling [18:58:42] durka42: Yes [18:58:53] 2) you can use std::env::args, which returns an iterator of the arguments, and then they're strings [18:58:56] and use .parse() to parse them [18:59:17] playbot-veno: let x: Option = "5".parse(); x [18:59:18] -playbot-veno- :9:30: 9:41 error: mismatched types: [18:59:18] -playbot-veno- expected `core::option::Option`, [18:59:18] -playbot-veno- output truncated; full output at: http://bit.ly/1WOl2wV [18:59:23] erickt: BTW, I created https://github.com/asajeffrey/parsell/issues/9 for you :) [18:59:23] oh right it's a result [18:59:45] playbot-veno: let x = "5.3".parse::(); x [18:59:46] ajeffrey: that'd be great [18:59:46] -playbot-veno- Ok(5.3) [19:00:07] oh and 1) should have said 'program argument handling', gah [19:00:18] To come back to my stringify question: would it be possible to have a macro that does something like: sh!(ls -l) ? right now the input gets interpreted as "ls - l" after a stringify [19:00:20] ajeffrey: we could write a syntax extension for parsell that makes it easier to provide better error messages ;) [19:00:26] (with a space between `-` and `l`) [19:00:50] mib_4ay0lr: macros receive their input as a series of tokens so it's not really possible to know whether it was sh!(ls -l) or sh!(ls - l) or sh!(ls- l) [19:00:53] *** Quits: espadrine (tyl@moz-gpr.c1p.152.213.IP) (Ping timeout: 121 seconds) [19:01:02] awww :( [19:01:03] mib_4ay0lr: Possible in theory, but not with macros as they are, since they don't do verbatim text replacement [19:01:09] *** Joins: jaen (jaen@moz-ifmik2.copit.pl) [19:01:11] and comments are removed, etc [19:01:20] my dreams are shattered [19:01:20] *** Joins: elyse (elyse@moz-dtjrv7.direct-adsl.nl) [19:01:22] sh!(ls /* rm -rf */ -l) is also possible :p [19:01:39] mib_4ay0lr: If it where a procedural macro you could access the raw source file span and extract i from there [19:01:45] *** Joins: mpark (mpark@moz-3jo6j8.ca.comcast.net) [19:01:47] *** Quits: teotwaki (teotwaki@moz-hqiu2s.s4a3.2e4u.41d0.2001.IP) (Ping timeout: 121 seconds) [19:02:23] but since those are not stable in any sense, it doesn't help you much I guess [19:02:30] erickt: :) [19:02:34] indeed [19:02:51] Is there an efficient way to reinterpret a Vec as a Vec? [19:03:08] assuming I know that the byte order in the Vec matches the system byte order [19:03:32] bob_twinkles: Efficient yes, guranteed to work in the future no idea [19:03:33] bob_twinkles: not as another Vec, since Vecs own their data [19:03:43] but you _could_ interpet a slice of its contents as one? i'd guess [19:03:51] *** Joins: teotwaki (teotwaki@moz-hqiu2s.s4a3.2e4u.41d0.2001.IP) [19:03:57] you can do it unsafely, but it seems like there is an alignment concern [19:04:00] bob_twinkles: Also, are those bytes correctly aligned for a u16? [19:04:06] yeah that ^ :) [19:04:17] I'd like to avoid copying the contents, since the vectors are decently large sized [19:04:25] I don't know, I'd have to care about how Vec allocates =P [19:04:35] kimundi: in practice probably? allocators generally don't actually hand out not-aligned chunks even if they're allowed to [19:05:02] *** Joins: firstdayonthejob (firstdayont@moz-bipmqq.cable.virginm.net) [19:05:19] *** Joins: mmalone (mmalone@moz-adr.u03.49.209.IP) [19:05:35] it seems like from_raw_parts() can do what I want, just I'm not sure what assumptions it makes and my brief perusal of the source didn't really clear it up [19:05:43] talchas: Well I don't generally like to recommend things that just _happen_ to work everywhere even though they are free to not do so :) [19:06:13] bob_twinkles: yeah, barring the alignment issue kimundi mentioned, it should be fine [19:06:22] bob_twinkles: Assumptions are that the alignment, length and type remain the same :P [19:06:34] kimundi: yeah, it's easy in C where malloc doesn't take an alignment parameter [19:06:54] (allocate it as Vec etc! :P) [19:06:58] I guess I can back up a level here and ask what the most efficient way to read system byte-order i16s out of a file [19:07:02] and that it uses the same allocator [19:07:03] (that doesn't actually work) [19:07:11] !crate byteorder [19:07:12] byteorder (0.4.2) - Library for reading/writing numbers in big-endian and little-endian. -> https://crates.io/crates/byteorder [19:07:16] talchas: I'd argue its even harder there, precisely because you don't control it [19:07:33] yeah, I'm using byteorder to pull out header information but it's painfully slow to do unbuffered u16 reads [19:07:38] kimundi: it means that malloc /must/ return sufficient alignment for the system [19:07:55] because by spec malloc(sizeof(any_type)) must work [19:08:11] ah, true malloc isn't actually paramtetric over the type [19:08:14] since you end up creating a io::Result and matching against it for every single u16 [19:08:36] which is fine if you only need to read a handful of metadata tags, but I'm trying to read in an entire uncompressed audio file =P [19:08:46] *** Joins: will_sm (will-medran@moz-09s.dbi.142.75.IP) [19:09:17] bob_twinkles: I feel like this should be possible efficently already, but I haven't done much io in Rust yet, so I'm not sure [19:09:43] *** Joins: brson (brson@moz-cfhap5.mtv2.mozilla.com) [19:09:43] *** ChanServ sets mode: +ao brson brson [19:09:46] http://is.gd/yRSrKa [19:10:55] *** Quits: _Vi (vi@moz-bbs.vhj.131.104.IP) (Ping timeout: 121 seconds) [19:11:22] *** Joins: ejpbruel (ejpbruel@moz-1r0f95.dynamic.ziggo.nl) [19:11:32] bob_twinkles: the easiest always-correct way is to allocate a Vec and then slice::from_raw_parts for the calls to read() [19:11:42] that won't let you just read_to_end though [19:11:56] Vec::from_raw_parts should work for that [19:12:37] *** Quits: mitaa (mitaa@moz-36dqvp.dyn.drei.com) (Client exited) [19:12:57] *** Joins: samx (sami@moz-oq8dni.dyn.optonline.net) [19:13:19] talchas: although malloc would be incorrect to use with Vec::from_raw_parts [19:13:37] *** Quits: areski (areski@moz-fvk8de.dynamic.jazztel.es) (Ping timeout: 121 seconds) [19:14:43] *** Joins: jonmorehouse (jonmorehous@moz-l7c.sbr.3.216.IP) [19:15:02] if I'm understanding correctly [19:15:04] Vec::from_raw_parts is more dangerous than slice::from_raw_parts because you're asking rust to pretend it allocated something other than what it really did [19:15:06] *** Quits: sepp2k (sepp2k@moz-7t23nq.isp.uni-luebeck.de) (Quit: Leaving.) [19:15:28] *** Quits: tillarnold (tillarnold@moz-hjsec5.ho1o.o6qc.1205.2a02.IP) (Ping timeout: 121 seconds) [19:16:01] *** Joins: sepp2k (sepp2k@moz-7t23nq.isp.uni-luebeck.de) [19:16:47] is it possible in theory that when dropping that vector, "please free the 8 u16's at address 0xDEADBEEF" is a different request than "please free the 16 u8's at address 0xDEADBEEF" [19:17:01] or does the allocator not have type info like that? [19:17:17] *** Joins: scriptor (scriptor@moz-qbtcmc.NATPOOL.NYU.EDU) [19:18:13] *** Quits: brianloveswords (brianlovesw@moz-n4t7m6.biz.rr.com) (Connection closed) [19:18:14] *** Joins: cruor99 (cruor99@moz-230so5.customer.cdi.no) [19:18:38] *** Quits: cruor99 (cruor99@moz-230so5.customer.cdi.no) (Quit: Leaving...) [19:18:42] durka42: no, but malloc != jemalloc [19:19:06] (and it's not guaranteed that we use jemalloc either) [19:19:20] well yeah [19:19:33] I'm not suggesting shuffling allocations between allocators [19:19:48] what I was wondering is if you can munge the type and capacity, as long as size_of * capacity is still the same [19:19:50] *** Quits: mmalone (mmalone@moz-adr.u03.49.209.IP) (Quit: My Mac has gone to sleep. ZZZzzz…) [19:20:05] yep [19:20:20] using Vec as a backing buffer is cool [19:20:21] (my function is missing an assert!(cap % 2 == 0), but it was an unsafe fn :D ) [19:20:23] at least, right now [19:20:27] *** Quits: mgottschlag (quassel@moz-fd9i0e.hsi6.kabel-badenwuerttemberg.de) (Ping timeout: 121 seconds) [19:20:54] *** Quits: zrsmith92 (textual@moz-3m7krt.dyn.suddenlink.net) (Quit: My Mac has gone to sleep. ZZZzzz…) [19:21:11] *** Joins: dzbarsky (Adium@moz-v18mcd.ca.comcast.net) [19:21:32] so for the foreseable future, I can just use something lke durka42's use_with_care(v: Vec) -> Vec? [19:21:40] *** Joins: kev_ (kevin_@moz-sni.32u.41.5.IP) [19:21:44] bob_twinkles: yeah, sure [19:21:54] it's not even unsafe [19:22:28] I mean the code inside is unsafe, but the function isn't [19:22:44] awesome, thanks [19:22:54] *** Joins: ubsan__ (ubsan@moz-l23ddu.r67r.odvl.fb90.2607.IP) [19:22:59] *** Joins: AlisdairO (anonymous@moz-ntsaoe.cable.virginm.net) [19:23:10] *** Quits: ubsan_ (ubsan@moz-cc6.3fu.114.66.IP) (NickServ (RECOVER command used by ubsan__)) [19:23:10] *** ubsan__ is now known as ubsan_ [19:23:11] *** Joins: zrsmith92 (textual@moz-0f2.kre.25.8.IP) [19:23:21] *** Joins: Eisfreak7 (Eisfreak7@moz-0fg8sh.pools.vodafone-ip.de) [19:23:29] ubsan_: to remove the unsafe keyword it at least needs assert!(len % 2 == 0 && cap % 2 == 0) [19:23:32] *** Joins: brianloveswords (brianlovesw@moz-n4t7m6.biz.rr.com) [19:23:53] bob_twinkles: ^ [19:23:55] also, don't do that thing [19:24:04] just take the end off of it [19:24:16] hm? [19:24:36] *** Joins: anjumkaiser (anjumkaiser@moz-26l.0t5.178.182.IP) [19:24:50] if v.len() % 2 != 0 { v.pop(); } v.truncate(); [19:25:14] bob_twinkles: ^ [19:25:18] *** Quits: dzbarsky (Adium@moz-v18mcd.ca.comcast.net) (Ping timeout: 121 seconds) [19:25:23] *** Joins: nZac (nZac@moz-2ehipf.midco.net) [19:25:25] *** Quits: erickt (erickt@moz-qie.6p3.217.74.IP) (Ping timeout: 121 seconds) [19:25:27] sure if you want that behavior [19:25:44] if you aren't sure whether it has the right size, and you want to avoid reallocation at all costs, it should probably return an Option or Result [19:26:10] (truncate has to reallocate and copy, no?) [19:26:23] it... might? [19:26:29] or could I do something like u8vec.reserve_exact(v.capacity() % 2) if v.capacity() % 2 != 0 [19:26:31] what [19:26:32] I guess [19:26:35] oh [19:26:38] bob_twinkles: curse you [19:26:40] *** Quits: chris_99 (chris_99@moz-g2jhk1.clients.your-server.de) (Ping timeout: 121 seconds) [19:26:45] *** Quits: Pierre (Pierre@moz-u8e5in.slkc.qwest.net) (Ping timeout: 121 seconds) [19:26:47] bob: sorry =( [19:27:03] *** Quits: micxjo (user@moz-psu8gk.fios.verizon.net) (A TLS packet with unexpected length was received.) [19:27:09] *** Quits: jincreator (jincreator@moz-mv2.45t.97.183.IP) (Connection closed) [19:27:10] oh I figured that was you [19:27:11] haha [19:27:14] yeah, you can figure it out tho [19:27:24] *** Quits: Eisfreak7 (Eisfreak7@moz-0fg8sh.pools.vodafone-ip.de) (Ping timeout: 121 seconds) [19:27:35] *** Joins: erickt (erickt@moz-qie.6p3.217.74.IP) [19:27:35] *** ChanServ sets mode: +ao erickt erickt [19:28:09] durka42: yes, alignment is one of the parameters that must be passed correctly to jemalloc when free'ing [19:28:14] *** Quits: brianloveswords (brianlovesw@moz-n4t7m6.biz.rr.com) (Connection closed) [19:28:19] anyways, gotta go [19:28:25] got a math test :/ [19:28:29] *** Quits: robotblake (robotblake@moz-0v636k.wa.comcast.net) (Quit: My Mac has gone to sleep. ZZZzzz…) [19:28:29] *** Quits: ubsan_ (ubsan@moz-l23ddu.r67r.odvl.fb90.2607.IP) (Quit: <3) [19:28:45] *** Quits: ]OLI[ (oli@moz-904c5e.sk83.bjud.7e00.2a01.IP) (Ping timeout: 121 seconds) [19:28:58] *** Joins: brianloveswords (brianlovesw@moz-n4t7m6.biz.rr.com) [19:29:08] bluss: so this technique depends on the "fact" that allocators don't return unaligned memory? [19:29:36] *** Joins: THIS-NICK-SUCKS (nan@moz-3fecuc.is.googolplex.ninja) [19:29:43] *** Joins: shadoi (shadoi@moz-24jpjh.ca.comcast.net) [19:30:02] hm.. what are you doing? [19:30:19] *** ahal|afk is now known as ahal [19:30:22] *** Joins: Nilabhra (nilabhra@moz-e0k.8dc.242.103.IP) [19:30:31] there is no guarantee that a Vec to Vec conversion ends well [19:30:33] *** Joins: mmalone (mmalone@moz-adr.u03.49.209.IP) [19:30:35] bluss: the above discussion was about using from_raw_parts to cast a Vec to Vec [19:31:05] sounds like this is a question we need to settle! [19:31:13] *** Joins: metathink (metathink@moz-k7ck7d.0bss.lncg.41d0.2001.IP) [19:31:23] you're in direct disagreement with ubsan (not that that surprises me) [19:31:25] *** Joins: ]OLI[ (oli@moz-1ufv47.members.linode.com) [19:31:42] it will work incidentally, but for me it's madness to give out guarantees [19:32:27] alignment + size must be the same when deallocating as allocating [19:32:43] if not, jemalloc may look in the wrong bin [19:33:36] *** Quits: mpark (mpark@moz-3jo6j8.ca.comcast.net) (Quit: My Mac has gone to sleep. ZZZzzz…) [19:34:24] *** Quits: zrsmith92 (textual@moz-0f2.kre.25.8.IP) (Ping timeout: 121 seconds) [19:34:33] hmm... what if I mem::forget() the Vec and leave the Vec? [19:35:00] *** Quits: fabiand (fabiand@moz-6in4qd.dip0.t-ipconnect.de) (Connection closed) [19:35:09] basically just use the Vec as a sort of reinterpreting view in to my Vec backing store [19:35:27] in that case don't use Vec::from_raw_parts at all [19:35:29] why not use &[u16] [19:35:32] instead use slice::from_raw_parts to get a &[u16] [19:35:33] yeah [19:36:18] *** Quits: FrozenCow (FrozenCow@moz-i2tvv4.chello.nl) (Quit: Leaving) [19:36:27] the docs don't give leeway for alignment http://doc.rust-lang.org/nightly/alloc/heap/fn.deallocate.html [19:37:04] ah, cool. That seems much cleaner [19:37:04] (the implementation details do) [19:37:34] they don't give leeway for size either :) [19:37:41] *** Quits: brianloveswords (brianlovesw@moz-n4t7m6.biz.rr.com) (Connection closed) [19:37:42] they do [19:38:02] er [19:38:04] oh it's a byte count [19:38:07] not element count [19:38:24] *** Quits: AlisdairO (anonymous@moz-ntsaoe.cable.virginm.net) (Client exited) [19:38:45] *** Joins: Nemo157_ (nemo157@moz-4426so.dyn.nltelcom.net) [19:38:50] *** Quits: Nemo157 (nemo157@moz-sqm0o8.dyn.nltelcom.net) (Ping timeout: 121 seconds) [19:39:13] maybe I'm repeating what has already been said, but there's no guarantee Vec (or any &[u8]) is properly aligned to be viewed as &[u16] [19:39:19] *** Joins: mpark (mpark@moz-3jo6j8.ca.comcast.net) [19:39:26] *** Joins: stephen (user@moz-to5njc.m7k5.54kg.0101.2620.IP) [19:39:31] although it probably is [19:39:41] *** zz_NameNotFound is now known as NameNotFound [19:40:04] *** Joins: brianloveswords (brianlovesw@moz-n4t7m6.biz.rr.com) [19:40:08] at least in the vec case [19:40:19] yeah, kimundi and talchas mentioned allignment [19:40:25] *** Quits: elyse (elyse@moz-dtjrv7.direct-adsl.nl) (Quit: Leaving) [19:40:26] *** NameNotFound is now known as zz_NameNotFound [19:40:28] *** Quits: brianloveswords (brianlovesw@moz-n4t7m6.biz.rr.com) (Quit: My Mac has gone to sleep. ZZZzzz…) [19:40:35] there any way for me to check that at runtime? [19:41:21] sure [19:41:32] not sure if there is a function for it in std, but it is just a simple bit-level operation on the pointer value itself [19:41:32] sure, when you get the pointer (that you will pass to from_raw_parts), check that (ptr as usize) % mem::align_of::() == 0 [19:41:36] *** Joins: joy (Adium@moz-f2g1h9.2rkg.9kg1.0101.2620.IP) [19:41:44] *** Joins: chris_99 (chris_99@moz-g2jhk1.clients.your-server.de) [19:42:01] ah, yep. Probably could have looked that up myself =P [19:42:08] at least that will work on machines where pointers are integers [19:42:15] god help us if rust is ever ported to a machine where that is not the case [19:42:27] *** Joins: joy1 (Adium@moz-ds7dj3.2rkg.9kg1.0101.2620.IP) [19:42:33] Pointers are strings! [19:42:40] i wouldn't put it past them, man [19:42:42] No Rust for the Mill then? :P [19:42:46] I don't think that can happen in 1.0 :) [19:42:49] kimundi: how do pointers work on Mill? [19:42:51] kmc: Pointers are UUIDs! =D [19:42:59] *** Quits: mpark (mpark@moz-3jo6j8.ca.comcast.net) (Quit: My Mac has gone to sleep. ZZZzzz…) [19:42:59] oh, there's mem::align_of_val [19:43:00] pointers are beautiful paintings of flowers [19:43:06] Hahaha [19:43:23] kmc: They are basically 1 flag bit, 3 tag bits, 60bits address [19:43:25] isn't a pointer a kind of dog [19:43:29] bob_twinkles: nice, that's great [19:43:30] *** Joins: awal_ (awal@moz-3a3.u30.98.14.IP) [19:43:42] kimundi: what do the flags and tag mean [19:44:13] bob_twinkles: are you doing lowlevel stuff too? ;) [19:44:14] *** Joins: manokara (manokara@moz-nuh.s95.179.179.IP) [19:44:15] bob_twinkles: wait, that doesn't do what I was thinking, of course [19:44:25] ehm, align_of_val doesn't actually look at the val [19:44:29] just the type [19:44:35] oh, darn [19:44:45] durka42: It probably looks at the value for DST [19:44:54] alignment is in the vtable [19:44:56] *** Joins: liquidmetal (liquidmetal@moz-u78kqf.fios.verizon.net) [19:44:59] anyway, that's the minimum alignment [19:45:00] kmc: I think it was a private/global flag neeeded to implement fork, and tag stuff to support efficient garbage collector [19:45:01] it's an intrinsic so who knows! [19:45:13] bob: not particularly, I'm trying read a RIFF WAVE file without creating and destroying a few million io::Results =P [19:45:13] bob_twinkles: kmc's code is the way [19:45:38] *** Quits: joy (Adium@moz-f2g1h9.2rkg.9kg1.0101.2620.IP) (Ping timeout: 121 seconds) [19:46:18] *** Quits: awal (awal@moz-6ls.15i.98.14.IP) (Ping timeout: 121 seconds) [19:46:51] kmc: Yes pointers are dogs [19:47:27] looks like align_of_val does inspect the vtable: http://is.gd/MiDcFr [19:47:28] *** Joins: eric_lagergren (eric@moz-5idrcj.wa.comcast.net) [19:47:50] *** Joins: AlisdairO (anonymous@moz-ntsaoe.cable.virginm.net) [19:47:50] *** Quits: Nilabhra (nilabhra@moz-e0k.8dc.242.103.IP) (Ping timeout: 121 seconds) [19:48:16] *** Joins: Guest37 (textual@moz-edsm98.res.rr.com) [19:48:56] *** Joins: Nilabhra (nilabhra@moz-e0k.8dc.242.103.IP) [19:49:16] *** Quits: Nemo157_ (nemo157@moz-4426so.dyn.nltelcom.net) (Ping timeout: 121 seconds) [19:49:22] *** Joins: blank_name (blank_name@moz-vae.aq8.36.50.IP) [19:49:36] pointers are just burritos [19:49:47] *** Joins: newbie (eibwen@moz-foett2.dip0.t-ipconnect.de) [19:49:49] durka42: So Monads == Pointers [19:49:51] :P [19:50:41] (http://blog.plover.com/prog/burritos.html) [19:50:41] *** Quits: scriptor (scriptor@moz-qbtcmc.NATPOOL.NYU.EDU) (Connection closed) [19:50:44] * durka42 has no idea what bluss is pointing at by "kmc's code") [19:50:45] *** Joins: scriptor (scriptor@moz-qbtcmc.NATPOOL.NYU.EDU) [19:51:07] using (ptr as usize) % mem::align_of::() [19:51:11] == 0 [19:51:23] oh for checking the alignment [19:52:01] *** Quits: jaysonsantos_ (quassel@moz-5dg.86n.210.62.IP) (Ping timeout: 121 seconds) [19:52:12] *** Joins: fyolnish (fyolnish@moz-8tfsb3.so-net.ne.jp) [19:52:16] *** panicbit2 is now known as panicbit [19:54:01] *** Joins: jaysonsantos (quassel@moz-5dg.86n.210.62.IP) [19:54:39] kimundi: I'm kind of bummed out to think that porting Rust to the Mill will be hard [19:55:06] *** Joins: areski (areski@moz-7o8r19.user.ono.com) [19:55:08] like the glorious future is already doomed by incompatibility [19:55:08] *** Quits: lidavidm (lidavidm@moz-45t74f.cit.cornell.edu) (Ping timeout: 121 seconds) [19:55:12] *** Joins: dpc (dpc@moz-j55hov.ahkg.bqct.0647.2601.IP) [19:55:18] kmc: Eh, nothing compared to the issues the mill team has with getting _llvm_ tio treat those pointers correctly :P [19:55:21] at least porting Rust to RISC-V should be straightforward [19:55:25] *** Quits: ferjm (textual@moz-nvpjsv.dynamicIP.rima-tde.net) (Quit: Textual IRC Client: www.textualapp.com) [19:55:25] *** Quits: scriptor (scriptor@moz-qbtcmc.NATPOOL.NYU.EDU) (Connection closed) [19:55:46] *** Joins: scriptor (scriptor@moz-qbtcmc.NATPOOL.NYU.EDU) [19:56:14] *** Quits: fyolnish (fyolnish@moz-8tfsb3.so-net.ne.jp) (Ping timeout: 121 seconds) [19:56:25] kmc: Is it inherent to the language (I don't see the problem there) or the compiler design? [19:56:29] (As in, llvm is used to compile to it, but it happily treats target-architecture pointers as integers in a lot of places) [19:56:34] (I only know a little about the mill, and nothing about rustc internals) [19:57:13] maurer: From what I know after watch 10+h of official mill presentation videos, I expect it to not be a big issue [19:57:31] *** Quits: wting (wting@moz-fl6.l5l.243.162.IP) (Connection closed) [19:58:00] kimundi: kmc just said otherwise, and while you've been helpful on here, I know that kmc doesn't just say random shit [19:58:22] *** Quits: SneakySnake (snake@moz-i9is4u.pool.telekom.hu) (Quit: Leaving) [19:59:00] *shrug* [19:59:18] *** Quits: jaysonsantos (quassel@moz-5dg.86n.210.62.IP) (Connection closed) [19:59:18] *** Joins: duncanlaird (chatzilla@moz-83kscv.mi.charter.com) [19:59:26] maurer: I say random shit sometimes [19:59:34] maurer: I was just thinking about Rust code that assumes pointers are integers [19:59:38] because I had just written some such code [19:59:48] *** Quits: scriptor (scriptor@moz-qbtcmc.NATPOOL.NYU.EDU) (Ping timeout: 121 seconds) [19:59:52] I certainly haven't watched 10+h of official mill presentation videos [20:00:02] *** Joins: sdleffler (sean@moz-fmptbr.hfc.comcastbusiness.net) [20:00:06] *** Joins: zrneely (zrneely@moz-su7vjd.dyn.mit.edu) [20:00:08] I'm guessing that a hypothetical Rust-Mill port would involve treating pointer values a bit more carefully in safe code, and maybe needing to explicitly use helper functions for pointer differences [20:00:11] OK [20:00:48] Might also be that its a non issue, in the sense that those 4 other bits just always have the same value for all raw pointer you'd compare anyway [20:00:48] *** Joins: jincreator (jincreator@moz-mv2.45t.97.183.IP) [20:01:11] Like, usually if you do stuff like that the pointers come from the same allocation [20:01:15] *** Joins: mstevens (mstevens@moz-itk2jg.etla.org) [20:01:22] *** Quits: pcwalton (pcwalton@moz-nh2.o1i.216.216.IP) (Client exited) [20:01:36] Is there such a thing as an associated static? Guessing no. [20:01:41] *** Quits: ziad (ziad@moz-s65gmp.ca.comcast.net) (Client exited) [20:01:45] *** Joins: Matthias247 (Miranda@moz-pfeurg.hsi7.kabel-badenwuerttemberg.de) [20:01:57] also, paging eddyb here because he does seem to have put more thought into what a Rust Mill port would entail :P [20:02:06] there will be associated consts at some point [20:02:07] kimundi: in C it's UB unless they come from the same allocation [20:02:09] but they are still too buggy to use [20:02:12] I don't know if LLVM inherits that [20:02:14] *Mill* [20:02:19] what is this even about [20:02:30] *** Joins: jaysonsantos (quassel@moz-5dg.86n.210.62.IP) [20:02:32] eddyb: Mill Architecture [20:02:38] durka42: I'm already using associated consts, and I know it's buggy - I actually ended up submitting a patch myself :P but you can't use a reference to an associated const [20:02:38] yes, what about it [20:02:51] sdleffler: associated statics are technologically impossible, sorry [20:02:59] it _was_ about casting a Vec to a Vec [20:03:02] no idea how we got to Mill :p [20:03:06] eddyb: Really!? Even non-mut ones? [20:03:06] eddyb: Wether Mills pointers would cause troubles if it became a target for Rust [20:03:13] sdleffler: you can put a reference in an associated const [20:03:27] sdleffler: statics are about having the same location in memory. which you can't with generics [20:03:37] *** Joins: dmac_ (dmac@moz-ajq52c.ca.comcast.net) [20:03:38] kimundi: less so than for C or C++ [20:03:46] eddyb: I guess that's true. Thanks for the ref-in-const tip. [20:03:59] the problem is LLVM generating ptrtoint casts were none were in the source IR [20:03:59] eddyb: Heh, indeed [20:04:01] *** Quits: sdleffler (sean@moz-fmptbr.hfc.comcastbusiness.net) (Quit: WeeChat 1.3) [20:04:10] *** Joins: chc4 (chc4@moz-9o2bj2.res.rr.com) [20:04:14] it seems possible but &A::S wouldn't be the same as &A::S [20:04:28] *** Joins: SmaugTheGreat (chatzilla@moz-44p3t9.dip0.t-ipconnect.de) [20:04:36] or it's deeper than that? [20:04:38] *** Joins: tillarnold (tillarnold@moz-hjsec5.ho1o.o6qc.1205.2a02.IP) [20:04:44] durka42: the problem is you need to guarantee that &A::S from two different places will result in the same address [20:05:02] I mean, *maybe* you could do that with symbol names... maybe [20:05:07] I mean... [20:05:10] *** Joins: brianloveswords (brianlovesw@moz-n4t7m6.biz.rr.com) [20:05:21] you also have to ensure that A::s() from different places calls the same function... [20:05:30] *** Joins: J_Arcane (chatzilla@moz-51cqqb.bb.dnainternet.fi) [20:05:32] durka42: yes and no [20:05:36] it has to do the same thing [20:05:44] I guess you could monomorphize it twice and nobody would notice [20:05:44] *** Quits: AlisdairO (anonymous@moz-ntsaoe.cable.virginm.net) (Client exited) [20:05:53] A::s as usize from two different places in the same program doesn't have to produce the same value [20:06:15] *** Joins: Guest5 (textual@moz-hnb58r.oc.cox.net) [20:06:24] that's surprising [20:06:30] *** Quits: Guest5 (textual@moz-hnb58r.oc.cox.net) (Quit: My Mac has gone to sleep. ZZZzzz…) [20:06:31] *** Quits: Guest37 (textual@moz-edsm98.res.rr.com) (Quit: My Mac has gone to sleep. ZZZzzz…) [20:06:48] it will in the same crate [20:06:57] but monomorphizations can be duplicated across crates [20:07:01] what's the point of systematic name mangling then! just give everything a UUID [20:07:50] *** Joins: waffles (wafflespean@moz-7bm.kbj.23.1.IP) [20:07:51] [20:42] at least that will work on machines where pointers are integers [20:07:52] [20:42] god help us if rust is ever ported to a machine where that is not the case [20:07:59] *** jdm is now known as jdm|busy [20:08:01] kmc: alignment checks would still work on the Mill [20:08:18] the top bits are what's funky about the integer representation of Mill pointers [20:08:34] and it has special instructions for pointer arithmetic [20:08:49] on my machine, the Llim, the least significant bits are the tags [20:08:52] :p [20:09:30] durka42: GCs do that, yes [20:09:30] *** Quits: brianloveswords (brianlovesw@moz-n4t7m6.biz.rr.com) (Connection closed) [20:09:38] *VMs with GC [20:09:57] a Smi in v8 is a 31-bit integer, shifted left by one bit, and the lowest bit set [20:10:27] it's cool that you can do a lot of operations with minimal or no changes [20:10:53] *** Parts: SmaugTheGreat (chatzilla@moz-44p3t9.dip0.t-ipconnect.de) ("") [20:11:00] *** Joins: scriptor (scriptor@moz-qbtcmc.NATPOOL.NYU.EDU) [20:11:11] AND and OR particularily, work just fine on the Smi representation [20:11:16] Anyone have a user experience report on Maud by lfairy? https://lfairy.gitbooks.io/maud/content/index.html [20:12:02] *** Quits: stephen (user@moz-to5njc.m7k5.54kg.0101.2620.IP) (Ping timeout: 121 seconds) [20:12:09] *** Joins: tarrant (tarrant@moz-bah.kjq.104.38.IP) [20:12:33] *** Joins: jeffbradberry (jrb@moz-nskkbv.res.rr.com) [20:13:07] *** Quits: RegulationD (RegulationD@moz-jpg5s7.ga.charter.com) (Connection closed) [20:14:10] *** Joins: laumann (thomas@moz-s86j9i.0.fullrate.ninja) [20:14:16] *** Joins: ubsan_ (ubsan@moz-cc6.3fu.114.66.IP) [20:14:37] *** Joins: nercury (nercury@moz-ngr949.static.zebra.lt) [20:14:38] *** Joins: ziad (ziad@moz-fh9.u9c.240.50.IP) [20:14:58] hello! :) [20:15:23] *** Joins: brianloveswords (brianlovesw@moz-n4t7m6.biz.rr.com) [20:15:38] nercury: Hey! :) [20:16:31] *** Joins: zrsmith92 (textual@moz-l4b.vbo.32.24.IP) [20:16:42] *** Joins: junqed (junqed@moz-9pe.2ap.70.178.IP) [20:16:51] *** Quits: zrsmith92 (textual@moz-l4b.vbo.32.24.IP) (Quit: My Mac has gone to sleep. ZZZzzz…) [20:17:51] *** Joins: dfockler (dan@moz-rm6ima.wa.comcast.net) [20:17:55] *** Joins: jga (asdf@moz-c1s.irn.129.186.IP) [20:18:40] *** Joins: mexisme (mexisme@moz-4m7bio.broadband.telstraclear.net) [20:19:15] *** Quits: brianloveswords (brianlovesw@moz-n4t7m6.biz.rr.com) (Connection closed) [20:20:03] *** Joins: mpark (mpark@moz-hud.3ra.116.199.IP) [20:20:34] *** Joins: AlisdairO (anonymous@moz-ntsaoe.cable.virginm.net) [20:20:48] *** Quits: Nilabhra (nilabhra@moz-e0k.8dc.242.103.IP) (Ping timeout: 121 seconds) [20:21:51] *** Quits: dardevelin (dardevelin@moz-nsbqhh.rev.vodafone.pt) (Quit: Leaving) [20:22:54] *** Joins: dardevelin (dardevelin@moz-nsbqhh.rev.vodafone.pt) [20:23:04] *** Joins: brianloveswords (brianlovesw@moz-n4t7m6.biz.rr.com) [20:23:17] *** Joins: Nilabhra (nilabhra@moz-e0k.8dc.242.103.IP) [20:26:04] *** Joins: slester (slester@moz-f33uhg.7nqd.tocq.e000.2605.IP) [20:27:48] *** Quits: jaysonsantos (quassel@moz-5dg.86n.210.62.IP) (A TLS packet with unexpected length was received.) [20:28:05] *** Joins: KiChjang (KiChjang@moz-19h7ll.dynamic.uwaterloo.ca) [20:28:20] is it possible to extend the lifetime of a variable by introducing lifetime parameters? [20:28:24] *** Joins: eckhardt_ (eckhardt@moz-kv4te9.hq.squareup.com) [20:28:52] *** Quits: ubsan_ (ubsan@moz-cc6.3fu.114.66.IP) (Connection closed) [20:28:59] no [20:29:06] lifetime parameters describe, they don't dictate [20:29:47] if the compiler is coercing a reference to have a shorter lifetime, in some cases you can prevent that by introducing more lifetime parameters [20:30:00] *** Joins: fabiand (fabiand@moz-41lla6.dip0.t-ipconnect.de) [20:30:29] *** Quits: mexisme (mexisme@moz-4m7bio.broadband.telstraclear.net) (Client exited) [20:31:02] *** Joins: jaysonsantos (quassel@moz-5dg.86n.210.62.IP) [20:31:29] so when i make a reference inside an if-block, i can't extend it to match the enclosing function's output reference's lifetime? [20:31:43] *** Quits: AlisdairO (anonymous@moz-ntsaoe.cable.virginm.net) (Client exited) [20:31:53] *** Quits: brianloveswords (brianlovesw@moz-n4t7m6.biz.rr.com) (Connection closed) [20:31:57] how can i solve this though? [20:32:06] *** Joins: ubsan_ (ubsan@moz-cc6.3fu.114.66.IP) [20:32:32] you mean if you create something inside a block and take a reference to it? [20:32:36] *** Joins: dinfuehr (dinfuehr@moz-1v6.2no.31.85.IP) [20:32:51] yes [20:32:59] and then extend its lifetime outside of the block [20:33:07] so the object you created will be deallocated at the end of the scope where it was declared [20:33:11] unless you move it somewhere else [20:33:43] well, it's not something created in a block, it's self.foo [20:33:57] all right, I need more detail now [20:34:00] *** Quits: jonmorehouse (jonmorehous@moz-l7c.sbr.3.216.IP) (Quit: WeeChat 1.3) [20:34:06] *** Joins: jonmorehouse (jonmorehous@moz-l7c.sbr.3.216.IP) [20:34:35] oh wait nvm [20:34:42] it looks like .as_ref() works [20:35:04] *** Quits: jincreator (jincreator@moz-mv2.45t.97.183.IP) (Client exited) [20:35:26] *** Joins: micxjo (user@moz-3d0.6oi.251.96.IP) [20:35:48] *** Quits: sogard (Mibbit@moz-bun.kgv.114.79.IP) (Quit: http://www.mibbit.com ajax IRC Client) [20:36:16] *** Quits: ubsan_ (ubsan@moz-cc6.3fu.114.66.IP) (Ping timeout: 121 seconds) [20:36:21] *** Quits: JanC (janc@moz-diemsm.dsl.scarlet.be) (Ping timeout: 121 seconds) [20:36:31] *** Quits: nZac (nZac@moz-2ehipf.midco.net) (Ping timeout: 121 seconds) [20:36:39] *** Quits: dinfuehr (dinfuehr@moz-1v6.2no.31.85.IP) (Ping timeout: 121 seconds) [20:36:59] *** Joins: Donkey_ (Donkey@moz-egs006.dyn.optonline.net) [20:37:19] *** Quits: japaric (japaric@moz-923.is2.230.201.IP) (Quit: WeeChat 1.4) [20:39:21] *** Quits: areski (areski@moz-7o8r19.user.ono.com) (Ping timeout: 121 seconds) [20:39:25] *** Quits: chc4 (chc4@moz-9o2bj2.res.rr.com) (Ping timeout: 121 seconds) [20:39:30] so in a buildscript, why would `env!("OUT_DIR")` work, but `env!("NUM_JOBS")` fail, when `std::env::var("NUM_JOBS")` works? [20:39:36] *** Parts: KiChjang (KiChjang@moz-19h7ll.dynamic.uwaterloo.ca) () [20:39:43] *** Joins: japaric (japaric@moz-923.is2.230.201.IP) [20:40:18] *** zz_NameNotFound is now known as NameNotFound [20:40:56] *** Joins: brianloveswords (brianlovesw@moz-n4t7m6.biz.rr.com) [20:41:15] dikaiosune: env! works at compile-time, env::var works at runtime [20:41:36] *** Quits: stelarcf_ (stelarcf@moz-3gh.lb8.81.92.IP) (Client exited) [20:41:37] *** Joins: espadrine (tyl@moz-rnqd9g.dd79.arl0.0e35.2a01.IP) [20:41:43] *** Joins: stelarcf_ (stelarcf@moz-3gh.lb8.81.92.IP) [20:41:56] but aren't buildscripts compiled by cargo when invoking a build command? so shouldn't those two times be like a couple milliseconds apart? does cargo not define num_jobs until after compiling the buildscript? [20:41:56] dikaiosune: evidently NUM_JOBS doesn't get set until the build script is actually run [20:42:08] right, that makes sense [20:42:25] *** Joins: kkus (kkus@moz-7u2hvh.fios.verizon.net) [20:42:44] *** Quits: mk (mk@moz-t0p.2l8.118.185.IP) (Ping timeout: 121 seconds) [20:42:47] *** Joins: AlisdairO (anonymous@moz-ntsaoe.cable.virginm.net) [20:42:50] *** Joins: japaric1 (japaric@moz-923.is2.230.201.IP) [20:43:32] this should be fixed or added as a note to http://doc.crates.io/environment-variables.html#environment-variables-cargo-sets-for-build-scripts [20:43:34] *** Quits: japaric1 (japaric@moz-923.is2.230.201.IP) (Quit: WeeChat 1.4) [20:43:39] *** Joins: japaric1 (japaric@moz-923.is2.230.201.IP) [20:43:47] *** Quits: japaric1 (japaric@moz-923.is2.230.201.IP) (Quit: WeeChat 1.4) [20:43:48] *** Quits: japaric (japaric@moz-923.is2.230.201.IP) (Ping timeout: 121 seconds) [20:43:56] *** Joins: japaric (japaric@moz-923.is2.230.201.IP) [20:44:14] i was just looking at making a PR [20:44:28] but if someone more familiar with cargo wants to, be my guest :) [20:44:28] *** Joins: solidsnack (solidsnack@moz-kro69u.ca.comcast.net) [20:44:41] *** Quits: mattrudder (textual@moz-l5tm8s.sntcca.sbcglobal.net) (Connection closed) [20:44:52] *** Joins: mk (mk@moz-t0p.2l8.118.185.IP) [20:47:09] *** Quits: brianloveswords (brianlovesw@moz-n4t7m6.biz.rr.com) (Connection closed) [20:48:05] *** Joins: brianloveswords (brianlovesw@moz-n4t7m6.biz.rr.com) [20:48:22] *** Joins: Shibe (Shibe@moz-00a.qn1.47.39.IP) [20:48:34] *** Joins: Eisfreak7 (Eisfreak7@moz-0fg8sh.pools.vodafone-ip.de) [20:48:35] whats the opposite of AsRef? [20:48:42] *** Quits: jonmorehouse (jonmorehous@moz-l7c.sbr.3.216.IP) (Quit: WeeChat 1.3) [20:48:45] i.e. convert the argument into a String if it's already not one [20:48:46] *** Quits: Eisfreak7 (Eisfreak7@moz-0fg8sh.pools.vodafone-ip.de) (Quit: WeeChat 1.4) [20:49:22] Shibe: ToOwned i think? [20:49:22] *** Joins: JanC (janc@moz-iarbou.dsl.scarlet.be) [20:49:33] yeah [20:49:49] niconii: yes but how do I take a function that does ToOwned for str/String [20:49:56] it doesn't seem to have a type argument like AsRef [20:50:02] so there's no ToOwned [20:50:10] *** Quits: AlisdairO (anonymous@moz-ntsaoe.cable.virginm.net) (Client exited) [20:50:17] *** Quits: sigma (sigma@moz-9epccp.cable.virginm.net) (Ping timeout: 121 seconds) [20:50:41] oh, well [20:51:14] *** jryans|away is now known as jryans [20:51:27] if it's a string you want in particular, you just want ToString [20:51:40] *** Joins: jonmorehouse (jonmorehous@moz-l7c.sbr.3.216.IP) [20:51:56] I'm using the mysql crate to read a table and one of the columns is a set. How can I get meaningful data out of this? [20:51:57] *** Quits: slester (slester@moz-f33uhg.7nqd.tocq.e000.2605.IP) (A TLS packet with unexpected length was received.) [20:51:58] consider Into too, Shibe [20:52:15] oh, yeah, Into may be a better idea [20:52:21] *** Quits: wldcordeiro (wldcordeiro@moz-ul1rm9.ut.comcast.net) (Ping timeout: 121 seconds) [20:52:32] *** Quits: cimes (cimes@moz-9e6.16c.135.128.IP) (Quit: Leaving) [20:52:57] ohh thanks [20:53:06] *** Quits: jonmorehouse (jonmorehous@moz-l7c.sbr.3.216.IP) (Quit: WeeChat 1.3) [20:53:06] Into is one of the argument conversion traits [20:53:11] (like AsRef) [20:53:21] *** Joins: makoLine (mako@moz-nokq4v.flip.co.nz) [20:53:42] *** Joins: nicholasf (nicholasf@moz-5hgefo.internode.on.net) [20:54:18] *** Quits: brianloveswords (brianlovesw@moz-n4t7m6.biz.rr.com) (Connection closed) [20:54:54] *** Quits: lutter (lutter@moz-7v7ueu.PUBLIC.monkeybrains.net) (Ping timeout: 121 seconds) [20:55:12] *** Joins: jonmorehouse (jonmorehous@moz-l7c.sbr.3.216.IP) [20:55:36] *** Quits: jonmorehouse (jonmorehous@moz-l7c.sbr.3.216.IP) (Quit: WeeChat 1.3) [20:55:41] *** Joins: mib_e3mspm (Mibbit@moz-222.os4.239.186.IP) [20:56:05] *** Quits: mib_e3mspm (Mibbit@moz-222.os4.239.186.IP) (Quit: http://www.mibbit.com ajax IRC Client) [20:56:58] *** Joins: UberLambda (uber@moz-c7o.hn7.36.94.IP) [20:57:08] *** Joins: lutter (lutter@moz-7v7ueu.PUBLIC.monkeybrains.net) [20:57:20] *** Joins: nimajneb (roytenberg@moz-8vs9l4.CWRU.Edu) [20:58:34] is there a "nice" way to delegate to the inner type when using the newtype pattern? [20:58:37] *** Quits: mmalone (mmalone@moz-adr.u03.49.209.IP) (Quit: My Mac has gone to sleep. ZZZzzz…) [20:58:40] *** Joins: bkearns1 (Adium@moz-rudtng.static.wiline.com) [20:58:40] *** Quits: bkearns (Adium@moz-rudtng.static.wiline.com) (Connection closed) [20:58:43] of do I have to write a bunch of boilerplate impls? [20:58:47] *or* [20:58:57] !crate newtype-derive [20:58:57] newtype_derive (0.1.4) - This crate provides macros for deriving common traits for newtype structures. -> https://crates.io/crates/newtype_derive [20:59:16] *** Joins: lucian_ (lucian@moz-n1l.htl.74.194.IP) [20:59:19] *** Joins: eheredia2511 (Mibbit@moz-222.os4.239.186.IP) [20:59:31] <_habnabit> omg i hoped this existed [20:59:33] *** Quits: eheredia2511 (Mibbit@moz-222.os4.239.186.IP) (Quit: http://www.mibbit.com ajax IRC Client) [21:00:07] *** Quits: eckhardt_ (eckhardt@moz-kv4te9.hq.squareup.com) (Connection closed) [21:00:18] *** Joins: brendan (brendaneich@moz-be03gd.sub-70-197-1.myvzw.com) [21:00:19] *** Joins: brianloveswords (brianlovesw@moz-n4t7m6.biz.rr.com) [21:00:19] durka42: that works on stable? (?!) [21:00:31] yeah [21:00:34] this is the magic https://danielkeep.github.io/rust-custom-derive/doc/newtype_derive/index.html#using-without-custom_derive [21:00:56] *** Joins: mmalone (mmalone@moz-adr.u03.49.209.IP) [21:01:29] <_habnabit> "That is, given a tuple struct with exactly one field" :( [21:01:38] <_habnabit> my tuple struct is (A, PhantomData) [21:02:09] *** Quits: lucian (lucian@moz-iuo.htl.74.194.IP) (Ping timeout: 121 seconds) [21:02:32] newtype derive doesn't support generic types at all [21:02:43] <_habnabit> awwww [21:02:44] ah in this case I want IntoIterator [21:02:45] <_habnabit> darn [21:02:47] sadface [21:03:12] it could though [21:03:18] *** Quits: lucian_ (lucian@moz-n1l.htl.74.194.IP) (Ping timeout: 121 seconds) [21:03:42] you just can't make a custom derive that adds bounds to the generic types [21:03:43] *** Quits: mpark (mpark@moz-hud.3ra.116.199.IP) (Quit: My Mac has gone to sleep. ZZZzzz…) [21:03:45] like the builtin ones do [21:03:52] *** Joins: AlisdairO (anonymous@moz-ntsaoe.cable.virginm.net) [21:05:27] *** Joins: wldcordeiro (wldcordeiro@moz-ul1rm9.ut.comcast.net) [21:05:38] *** Quits: brianloveswords (brianlovesw@moz-n4t7m6.biz.rr.com) (Connection closed) [21:06:01] *** Joins: jonmorehouse (jonmorehous@moz-l7c.sbr.3.216.IP) [21:06:37] *** Quits: p32blo (p32blo@moz-gbnpoc.di.uminho.pt) (Ping timeout: 121 seconds) [21:07:29] *** Quits: jonmorehouse (jonmorehous@moz-l7c.sbr.3.216.IP) (Quit: WeeChat 1.3) [21:07:43] *** Joins: tikue (tikue@moz-6arsnf.26es.bi7c.0647.2601.IP) [21:07:45] *** Quits: ysgard (ysgard@moz-2f2.ndk.196.69.IP) (Ping timeout: 121 seconds) [21:08:04] *** Quits: kev_ (kevin_@moz-sni.32u.41.5.IP) (Ping timeout: 121 seconds) [21:08:07] *** Joins: Kocka (Thunderbird@moz-64vniv.dynamic.ziggo.nl) [21:08:21] *** Joins: brianloveswords (brianlovesw@moz-n4t7m6.biz.rr.com) [21:08:50] *** Quits: orangeshark (erik@moz-pdc35c.44tj.56ot.0306.2602.IP) (Quit: Leaving) [21:10:03] *** Quits: ejpbruel (ejpbruel@moz-1r0f95.dynamic.ziggo.nl) (Quit: leaving) [21:11:02] *** Joins: _Vi (vi@moz-bbs.vhj.131.104.IP) [21:11:45] *** Quits: tikue (tikue@moz-6arsnf.26es.bi7c.0647.2601.IP) (Ping timeout: 121 seconds) [21:12:05] *** Quits: anjumkaiser (anjumkaiser@moz-26l.0t5.178.182.IP) (Quit: Leaving.) [21:12:22] *** Quits: AlisdairO (anonymous@moz-ntsaoe.cable.virginm.net) (Client exited) [21:12:23] *** Quits: brianloveswords (brianlovesw@moz-n4t7m6.biz.rr.com) (Connection closed) [21:12:25] *** Joins: RegulationD (RegulationD@moz-jpg5s7.ga.charter.com) [21:13:50] *** Joins: brianloveswords (brianlovesw@moz-n4t7m6.biz.rr.com) [21:15:25] *** Quits: erickt (erickt@moz-qie.6p3.217.74.IP) (Ping timeout: 121 seconds) [21:15:37] *** Joins: pcwalton (pcwalton@moz-l8ebtf.sfo1.mozilla.com) [21:15:37] *** ChanServ sets mode: +ao pcwalton pcwalton [21:16:03] *** Joins: eckhardt_ (eckhardt@moz-kv4te9.hq.squareup.com) [21:16:10] *** Quits: eckhardt_ (eckhardt@moz-kv4te9.hq.squareup.com) (Quit: Leaving...) [21:17:36] *** Quits: crunchiebones (jy@moz-5uf.jl4.74.188.IP) (Ping timeout: 121 seconds) [21:17:49] *** Quits: jfo (jfo@moz-k3r.ebo.124.64.IP) (Connection closed) [21:18:11] bluss: apparently Into isn't implemented? [21:18:12] *** Joins: AlisdairO (anonymous@moz-ntsaoe.cable.virginm.net) [21:18:15] atleast not according to the docs it isnt [21:18:26] *** jdm|busy is now known as jdm [21:18:39] *** Joins: musiKk (foobar@moz-ecd8ku.pools.vodafone-ip.de) [21:19:07] *** Quits: AlisdairO (anonymous@moz-ntsaoe.cable.virginm.net) (Client exited) [21:19:16] *** Joins: Eisfreak7 (Eisfreak7@moz-0fg8sh.pools.vodafone-ip.de) [21:19:19] playbot-veno: let x: String = "foo".into(); [21:19:20] -playbot-veno- () [21:19:56] playbot-veno: let x: String = "foo".into(); x [21:19:57] -playbot-veno- "foo" [21:20:01] huh [21:20:05] then the docs dont have Into [21:20:27] *** Quits: brianloveswords (brianlovesw@moz-n4t7m6.biz.rr.com) (Connection closed) [21:21:11] Shibe: it comes from the blanket impl http://doc.rust-lang.org/std/convert/trait.Into.html [21:21:20] impl Into for T where U: From [21:21:34] oh [21:22:08] *** Joins: dzbarsky (Adium@moz-v18mcd.ca.comcast.net) [21:22:24] and impl<'a> From<&'a str> for String [21:22:31] this stuff is a bit confusing [21:22:32] *** Joins: brianloveswords (brianlovesw@moz-n4t7m6.biz.rr.com) [21:22:43] *** Quits: andre_ (andre@moz-rnd.3qv.76.201.IP) (Quit: leaving) [21:22:49] it works like magic though :-) [21:22:52] *** Joins: pereba (pereba@moz-cg8akr.jg6p.u671.07f2.2804.IP) [21:23:59] *** Quits: rubdos (rubdos@moz-l7lf2c.access.telenet.be) (Quit: Leaving) [21:26:11] *** Quits: dzbarsky (Adium@moz-v18mcd.ca.comcast.net) (Ping timeout: 121 seconds) [21:26:18] http://i.shibe.ml/QmPs9jRonYY5pSvyq6tk6EMFdpzAedx1sKMsFJmBiAmMk4.png [21:26:22] <_habnabit> http://is.gd/TiDjt5 where is the 'Self: Sized' constraint coming from? is it that it's deriving from Clone, which has a -> Self method? [21:26:26] what's the correct way to do this? [21:26:47] *** Quits: laumann (thomas@moz-s86j9i.0.fullrate.ninja) (Ping timeout: 121 seconds) [21:27:00] <_habnabit> Shibe, just implement From, not From and Into both [21:27:13] *** Joins: laumann (thomas@moz-s86j9i.0.fullrate.ninja) [21:27:50] *** Joins: jfo (jfo@moz-k3r.ebo.124.64.IP) [21:28:04] *** Quits: scriptor (scriptor@moz-qbtcmc.NATPOOL.NYU.EDU) (Connection closed) [21:28:04] _habnabit: I'm trying to make it so that I can pass both &str and String [21:28:39] *** Joins: blackgoat (blackgoat@moz-stj.iu0.157.221.IP) [21:28:45] <_habnabit> Shibe, pass where? maybe you just want to make your parameter Into [21:28:54] *** Quits: cite-reader (ahill@moz-pv1j2k.swbr.surewest.net) (Quit: leaving) [21:29:13] Shibe: your png was confusing because [21:29:47] > echo $HOME [21:29:47] /home/kamal [21:30:18] lol my name is also kamal [21:30:39] :p [21:30:58] anyway, prefer to implement From<> where you can [21:31:03] *** Joins: robotblake (robotblake@moz-0v636k.wa.comcast.net) [21:31:13] _habnabit: my immediate reaction is that implementing a trait for another trait doesn't really make sense. https://play.rust-lang.org/?gist=00d2479c3caf94788118&version=nightly [21:31:22] *** Joins: TimNN (TimNN@moz-r8l.9ss.89.141.IP) [21:31:24] *** Quits: jeffbradberry (jrb@moz-nskkbv.res.rr.com) (Ping timeout: 121 seconds) [21:31:27] reserving Into<> for cases where coherence won't let you [21:31:37] <_habnabit> Ketsuban, oh, that does make more sense [21:31:38] *** Quits: mmalone (mmalone@moz-adr.u03.49.209.IP) (Quit: My Mac has gone to sleep. ZZZzzz…) [21:32:00] <_habnabit> Ketsuban, what's the semantic difference between that and what i had? [21:32:10] <_habnabit> Ketsuban, i guess what i had requires trait objects [21:32:22] yes but I'm still not quite sure how I can have fn from() be able to take a &str or a String [21:32:40] ah [21:32:40] *** Quits: dpc (dpc@moz-j55hov.ahkg.bqct.0647.2601.IP) (Ping timeout: 121 seconds) [21:32:45] then you declare it as [21:33:00] <_habnabit> Shibe, i don't think From is the right thing to do here. just `fn new(buffer: Into) -> Response` [21:33:05] think i've seen it here, but can't recall nor find in the man - is there any sane way to ask rustc to spit the exact infered binding types? [21:33:30] *** Joins: dinfuehr (dinfuehr@moz-1v6.2no.31.85.IP) [21:33:36] Shibe: can you paste some code in play? [21:33:47] _habnabit: yes but the From implementation would only work with Strings if I did From and not string slices too [21:33:49] kamalmarhubi: ok [21:33:52] *** Joins: tristans1 (tristanseif@moz-aqblut.res.rr.com) [21:33:57] Shibe: is response always taking ownership? [21:34:05] yeah [21:34:06] *** Quits: brendan (brendaneich@moz-be03gd.sub-70-197-1.myvzw.com) (Connection closed) [21:34:10] sorta need ownership of the string [21:34:13] (or copying) [21:34:30] <_habnabit> polezaivsani, -Z unstable-options --unpretty=expanded,identified [21:34:48] because you *may* want a lifetime parameter on Response, as in Response<'a>, and store &'a str inside it [21:34:52] kamalmarhubi: https://gist.github.com/anonymous/a98f56d475e33cf75468 [21:34:58] depending on how allocation / copy averse you are [21:35:00] https://gist.github.com/anonymous/a98f56d475e33cf75468#file-lib-rs-L22 [21:35:04] _habnabit: thank you! [21:35:26] <_habnabit> Shibe, yeah, don't bother with From; that's not really what From is for [21:35:37] Shibe: You may be interested in .clone() [21:35:50] *** Joins: Pierre (Pierre@moz-u8e5in.slkc.qwest.net) [21:35:56] <_habnabit> Shibe, just do `imp Response { fn new(buf: Into>) { Response::Buffer(buf) } }` [21:36:06] *** Joins: wting (wting@moz-fl6.l5l.243.162.IP) [21:36:09] <_habnabit> oops, fix the obvious typos there [21:36:13] *** Quits: brianloveswords (brianlovesw@moz-n4t7m6.biz.rr.com) (Connection closed) [21:36:44] _habnabit: yes but wouldn't that mean that at one point or another I'd have to check whether Buffer is valid utf-8 and then set Content-Type to text/plain before sending to client? [21:36:51] Was hoping to use enum instead [21:36:53] *** Joins: elyse (elyse@moz-dtjrv7.direct-adsl.nl) [21:37:25] *** Joins: erickt (erickt@moz-qie.6p3.217.74.IP) [21:37:25] *** ChanServ sets mode: +ao erickt erickt [21:37:27] <_habnabit> Shibe, why would it mean that? [21:37:30] *** Quits: robotblake (robotblake@moz-0v636k.wa.comcast.net) (Quit: My Mac has gone to sleep. ZZZzzz…) [21:37:33] *** Quits: dinfuehr (dinfuehr@moz-1v6.2no.31.85.IP) (Ping timeout: 121 seconds) [21:38:02] _habnabit: doesn't seem to tell all the gory details regarding types :( [21:38:07] _habnabit: because if it were text I'd have to set content-type header so that browser can detect it [21:38:36] *** Quits: TimNN (TimNN@moz-r8l.9ss.89.141.IP) (Quit: My Mac has gone to sleep. ZZZzzz…) [21:38:52] <_habnabit> Shibe, oh, i see what you're trying to do [21:39:11] *** Joins: robotblake (robotblake@moz-0v636k.wa.comcast.net) [21:39:16] *** Joins: mpark (mpark@moz-hud.3ra.116.199.IP) [21:39:39] <_habnabit> Shibe, `impl Response { pub fn new_bag_of_bytes>> -> Response ... pub fn new_with_utf8> -> Response ... }` [21:39:46] <_habnabit> Shibe, make two separate methods [21:40:03] *** Joins: Salvakiya (Salvakiya@moz-9am32a.range109-155.btcentralplus.com) [21:40:11] *** Quits: Salvakiya (Salvakiya@moz-9am32a.range109-155.btcentralplus.com) (Quit: Leaving) [21:40:36] ok [21:40:43] *** Quits: thiblahute_ (tsaunier@moz-68f5rr.rev.sfr.net) (Ping timeout: 121 seconds) [21:42:35] *** Joins: brianloveswords (brianlovesw@moz-n4t7m6.biz.rr.com) [21:43:00] <_habnabit> polezaivsani, such as? [21:44:02] _habnabit: let x = Box::new([1,2,3]) - doesn't show the x's type [21:44:18] <_habnabit> polezaivsani, maybe it's hir,typed that does it [21:45:11] _habnabit: sorry, `hir,typed` - don't get it? [21:45:18] <_habnabit> polezaivsani, --pretty=hir,typed [21:45:35] *** Joins: lucian (lucian@moz-7hsb6f.cable.virginm.net) [21:45:42] I think it's --unpretty=hir,typed :) [21:45:49] there's also a quick trick [21:45:53] you just provoke a type error [21:45:56] <_habnabit> oops yes --unpretty [21:46:01] let _: () = expression_you_would_like_to_typecheck; [21:46:12] <_habnabit> heh [21:46:20] much easier to read than the unpretty output :) [21:47:10] *** Joins: Nemo157 (nemo157@moz-2iic15.dyn.nltelcom.net) [21:47:48] _habnabit, durka42: that's enough type info to get me going for a while :) thanks [21:48:32] *** Quits: brianloveswords (brianlovesw@moz-n4t7m6.biz.rr.com) (Connection closed) [21:49:09] Is it possible (using `unsafe` code) to write a function `(&'a [T]) -> Result<&'a [T; LEN], ()>`? Here's my attempt, which doesn't work: http://is.gd/D9ASok [21:49:09] *** Joins: thiblahute_ (tsaunier@moz-68f5rr.rev.sfr.net) [21:49:24] *** Joins: brianloveswords (brianlovesw@moz-n4t7m6.biz.rr.com) [21:49:37] *** Quits: lucian (lucian@moz-7hsb6f.cable.virginm.net) (Ping timeout: 121 seconds) [21:50:52] *** Quits: nimajneb (roytenberg@moz-8vs9l4.CWRU.Edu) (Client exited) [21:51:05] briansmith: yes [21:51:31] *** Quits: Nemo157 (nemo157@moz-2iic15.dyn.nltelcom.net) (Ping timeout: 121 seconds) [21:51:37] bluss: How? [21:51:43] !crate arrayref [21:51:44] arrayref (0.3.2) - Macros to take array references of slices -> https://crates.io/crates/arrayref [21:51:49] you can use this approach [21:52:02] *** Quits: waffles (wafflespean@moz-7bm.kbj.23.1.IP) (Quit: C'yall later...) [21:52:21] I think it does it right http://droundy.github.io/arrayref/arrayref/macro.array_ref!.html [21:52:22] *** Quits: Nilabhra (nilabhra@moz-e0k.8dc.242.103.IP) (Connection closed) [21:52:44] blank, take "array references of slices"... what on earth does that even mean? :P [21:52:47] it's not possible to be dynamic about the length [21:52:48] *** Quits: joy1 (Adium@moz-ds7dj3.2rkg.9kg1.0101.2620.IP) (Quit: Leaving.) [21:52:49] *** Joins: joy (Adium@moz-u3dg2t.sfo1.mozilla.com) [21:53:32] Noldorin ping? [21:53:43] but if you had a trait that represented "this type is an array" you could at least implement a function for all array lengths [21:53:46] blank, ? [21:53:54] (and that trait is in libcore but unstable) [21:54:28] one could possibly use such a trait to maken [T: Clone; N] Clone :) [21:54:34] *** Joins: fyolnish (fyolnish@moz-8tfsb3.so-net.ne.jp) [21:54:59] not sure if coherence will cooperate with that [21:55:09] probably needs specialization [21:55:22] or sprinkle #[fundamental] around until the errors stop ;) [21:55:35] 3[fundamental]? [21:55:59] A trait for trait objects is similarly useful [21:56:18] *** Quits: joy (Adium@moz-u3dg2t.sfo1.mozilla.com) (Quit: Leaving.) [21:56:19] *** Joins: joy (Adium@moz-ds7dj3.2rkg.9kg1.0101.2620.IP) [21:56:22] hoverbear: an unstable coherence-escape-hatch for the stdlib... don't worry about it [21:56:42] it indicates that implementing that trait for a type can be a breaking change [21:56:46] durka42: Hmm >.> [21:56:49] *** Joins: ff (flaper87Moz@moz-ql4.mp2.101.148.IP) [21:57:30] still can't make (T: Clone, U: Clone, ...): Clone though [21:57:49] *** Quits: dellavg (dellavg@moz-iva.9jl.232.95.IP) (Ping timeout: 121 seconds) [21:57:49] bluss: Thanks!: http://is.gd/qDOAUM [21:57:55] oh actually I think it is a marker on types not traits [21:58:25] Now, is there any reason that this function would be unsafe to use? [21:58:25] *** AutomatedTester is now known as AutomatedTester|AFK [21:58:28] *** Quits: brianloveswords (brianlovesw@moz-n4t7m6.biz.rr.com) (Quit: My Mac has gone to sleep. ZZZzzz…) [21:58:32] e.g. memory model reasons [21:58:34] nope it’s for traits [21:58:46] so e.g. Fn, FnMut, etc. are #[fundamental] [21:58:51] which means implementing them for a type is a breaking change [21:59:00] types can also have #[fundamental] [21:59:01] (Box does) [21:59:14] *** Joins: brianloveswords (brianlovesw@moz-n4t7m6.biz.rr.com) [21:59:28] from libcore, an example of why FnMut is fundamental: so that regex can rely that `&str: !FnMut` [21:59:37] *** Quits: fyolnish (fyolnish@moz-8tfsb3.so-net.ne.jp) (Ping timeout: 121 seconds) [22:00:35] *** AutomatedTester|AFK is now known as AutomatedTester [22:00:45] briansmith: I don't think so. It's bounds checked and borrows the input correctly [22:01:13] *** Joins: JagaJaga (JagaJaga@moz-ua8.hhl.62.178.IP) [22:02:29] *** Quits: erickt (erickt@moz-qie.6p3.217.74.IP) (Ping timeout: 121 seconds) [22:03:10] *** Joins: erickt (erickt@moz-qie.6p3.217.74.IP) [22:03:10] *** ChanServ sets mode: +ao erickt erickt [22:03:12] *** Joins: Eisfreak1 (Eisfreak7@moz-0fg8sh.pools.vodafone-ip.de) [22:04:03] *** Joins: awal (awal@moz-vmu.a4l.98.14.IP) [22:04:21] *** Joins: TimNN (TimNN@moz-r8l.9ss.89.141.IP) [22:04:23] If I want to match on a struct content like `{ foo: 1, bar: "two" }` in a macro, which fragment specifier should I use? [22:05:42] *** Joins: slester (slester@moz-28gr00.res.rr.com) [22:05:44] *** Quits: slester (slester@moz-28gr00.res.rr.com) (A TLS packet with unexpected length was received.) [22:05:45] *** Joins: slester (slester@moz-f33uhg.7nqd.tocq.e000.2605.IP) [22:06:22] *** Quits: awal_ (awal@moz-3a3.u30.98.14.IP) (Ping timeout: 121 seconds) [22:06:29] fabrice: expr or tt [22:06:45] actually I'm not sure that matches expr [22:08:09] durka42: currently using tt without success: [22:08:20] playbot-veno: macro_rules! is_expr { ($e:expr) => { true }; ($($t:tt)*) => { false } } is_expr!({ foo: 1, bar: "two" }) [22:08:21] -playbot-veno- :9:97: 9:98 error: expected one of `!`, `.`, `::`, `;`, `{`, `}`, or an operator, found `:` [22:08:21] -playbot-veno- :9 macro_rules! is_expr { ($e:expr) => { true }; ($($t:tt)*) => { false } } is_expr!({ foo: 1, bar: "two" }) [22:08:21] -playbot-veno- output truncated; full output at: http://bit.ly/1Tcq2hm [22:08:27] whoops [22:08:38] *** Joins: scoopr (scoopr@moz-fc6cp1.fi) [22:08:40] https://irccloud.mozilla.com/pastebin/Val8jZrT [22:09:08] fabrice: the entire {...} is a tt [22:09:17] right, just saw that [22:10:08] also I anticipate you are going to need one of these :) [22:10:09] !as_expr [22:10:09] https://danielkeep.github.io/tlborm/book/blk-ast-coercion.html [22:10:32] *** AutomatedTester is now known as AutomatedTester|AFK [22:10:37] durka42: what's that? [22:10:46] *** Quits: Kocka (Thunderbird@moz-64vniv.dynamic.ziggo.nl) (Client exited) [22:10:50] converters to help rust parse the output of the macro [22:10:55] they are often needed when working with tt's [22:11:26] but don't worry about it yet [22:11:33] wait until you get an inscrutable parse error :p [22:11:49] *** Quits: micxjo (user@moz-3d0.6oi.251.96.IP) (Ping timeout: 121 seconds) [22:12:05] right now it's complaining about $x because it expects an identifier [22:12:33] where? [22:13:13] fabrice: hmm this isn't exactly going to work [22:13:22] you'll need to parse a little deeper [22:13:29] *** Joins: ubsan_ (ubsan@moz-cc6.3fu.114.66.IP) [22:13:31] you can't declare a struct without knowing the types :/ [22:13:34] *** Quits: zrneely (zrneely@moz-su7vjd.dyn.mit.edu) (Ping timeout: 121 seconds) [22:13:35] *** Quits: erickt (erickt@moz-qie.6p3.217.74.IP) (Ping timeout: 121 seconds) [22:13:55] right [22:14:21] does std have any "io buffer" type, which implements Read+Write, acts kind of like a file, that I could use instead of a file in tests? [22:14:47] Vec has Write but no Read :P [22:15:00] what's the special ability that FnOnce has that Fn/FnMut doesn't have and makes it the superior choice on determined scenarios? [22:15:12] scoopr: Cursor [22:15:23] *** Quits: sepp2k (sepp2k@moz-7t23nq.isp.uni-luebeck.de) (Quit: Leaving.) [22:15:30] darkstalker: FnOnce can only be called once, so it can move and drop stuff [22:15:34] scoopr: I know it does not answer your question, but when testing I often use: https://crates.io/crates/tempfile [22:16:00] *** Quits: jgallagher (john@moz-d5e8oc.hfc.comcastbusiness.net) (Client exited) [22:16:06] durka42, ooh! [22:16:39] durka42, but what about `move || ...`, doesn't that move the environment for the other types too? [22:16:53] that's different [22:17:02] that's the confusion i have atm [22:17:14] move || ... means to move the captures in when creating the closure [22:17:31] however, a FnMut move closure still can't move out of a capture, or drop it, because the closure could be called again [22:18:52] but FnOnce can still be move and non-move right? .. i mean it still can borrow things [22:19:09] move is totally orthoganal to each Fn* type [22:19:14] there's six combinations [22:19:15] darkstalker: FnOnce can move _out_ of env, move || can move _in_ env [22:19:16] so it's a dinstinction between moving *in* andd moving *out* [22:19:27] oh right [22:19:54] How do I make a vector of structs? [22:19:56] so if i want to capture and return a value, only FnOnce can do it [22:20:47] yeah [22:20:52] ok, thanks :3 [22:20:58] LambdaComplex: same as a vector of anything else [22:21:04] Vec [22:21:40] *** Quits: amyers (amyers@moz-qn874b.zip.zayo.com) (Ping timeout: 121 seconds) [22:21:41] bluss: Thanks for your help! [22:21:55] <_habnabit> if i have parameterized implementations with `where` bounds, is there a way way to see why that implementation wasn't chosen or usable for some combination of input types? [22:23:02] durka42: Okay, lemme rephrase. What's the syntax for defining the entries in a Vec? [22:23:05] *** Quits: brianloveswords (brianlovesw@moz-n4t7m6.biz.rr.com) (Connection closed) [22:23:15] *** Joins: brianloveswords (brianlovesw@moz-n4t7m6.biz.rr.com) [22:23:26] my answer is the same, though I know that isn't helpful :) [22:23:41] LambdaComplex - vec![Struct::new(), Struct::with_foo(42)] [22:23:42] *** Quits: fabiand (fabiand@moz-41lla6.dip0.t-ipconnect.de) (Quit: Verlassend) [22:23:51] playbot-veno: #[derive(Debug)] struct Foo { x: i32 } vec![Foo { x: 1 }, Foo { x: 2 }] [22:23:52] -playbot-veno- [Foo { x: 1 }, Foo { x: 2 }] [22:24:14] LambdaComplex - That's a macro. You can also use Vec::new(), then .push or .extend. [22:24:43] *** Joins: nimajneb (roytenberg@moz-plckos.CWRU.Edu) [22:24:56] *** Quits: nimajneb (roytenberg@moz-plckos.CWRU.Edu) (Client exited) [22:25:34] *** Quits: gopar (gopar@moz-5039uj.ca.comcast.net) (A TLS packet with unexpected length was received.) [22:25:37] durka42: Okay, that last part answered my question :P [22:25:37] *** Quits: brianloveswords (brianlovesw@moz-n4t7m6.biz.rr.com) (Connection closed) [22:25:47] *** Joins: brianloveswords (brianlovesw@moz-n4t7m6.biz.rr.com) [22:26:06] *** Quits: manokara (manokara@moz-nuh.s95.179.179.IP) (Quit: Vanished) [22:27:48] *** Quits: brianloveswords (brianlovesw@moz-n4t7m6.biz.rr.com) (Connection closed) [22:27:58] *** Joins: brianloveswords (brianlovesw@moz-n4t7m6.biz.rr.com) [22:29:34] *** Quits: mib_4ay0lr (Mibbit@moz-d35klc.CS.McGill.CA) (Quit: http://www.mibbit.com ajax IRC Client) [22:32:27] *** Joins: iceiceice (chris@moz-n3v1ju.ias.edu) [22:33:18] *** Quits: robotblake (robotblake@moz-0v636k.wa.comcast.net) (Quit: My Mac has gone to sleep. ZZZzzz…) [22:33:23] *** Joins: jeffbradberry (jrb@moz-mrjdh9.rlghnc.sbcglobal.net) [22:33:44] *** Quits: musiKk (foobar@moz-ecd8ku.pools.vodafone-ip.de) (Ping timeout: 121 seconds) [22:34:01] *** Quits: Eisfreak1 (Eisfreak7@moz-0fg8sh.pools.vodafone-ip.de) (Quit: WeeChat 1.4) [22:34:25] *** Joins: dinfuehr (dinfuehr@moz-1v6.2no.31.85.IP) [22:34:27] *** Quits: Eisfreak7 (Eisfreak7@moz-0fg8sh.pools.vodafone-ip.de) (Quit: WeeChat 1.4) [22:34:52] *** Joins: Eisfreak7 (Eisfreak7@moz-0fg8sh.pools.vodafone-ip.de) [22:35:34] *** Parts: polezaivsani (polezaivsan@moz-k35vmr.baltnet.ru) ("ii - 500 SLOC are too much") [22:35:39] *** Joins: Eisfreak1 (Eisfreak7@moz-0fg8sh.pools.vodafone-ip.de) [22:35:47] *** Quits: Eisfreak1 (Eisfreak7@moz-0fg8sh.pools.vodafone-ip.de) (Quit: WeeChat 1.4) [22:35:58] *** Quits: ato (sid11@moz-c1oek8.0j4i.jtu0.0101.2620.IP) (Quit: ) [22:35:58] Is it possible to create a macro that accesses the scope from which it's called, without passing in a variable? [22:36:00] *** Quits: Eisfreak7 (Eisfreak7@moz-0fg8sh.pools.vodafone-ip.de) (Quit: WeeChat 1.4) [22:36:39] *** Quits: elyse (elyse@moz-dtjrv7.direct-adsl.nl) (Quit: Leaving) [22:37:03] *** Joins: rakm (rakm@moz-0hc.gir.115.17.IP) [22:37:14] *** Quits: erikj (erikj@moz-aj5go8.jki.re) (Ping timeout: 121 seconds) [22:37:41] feti: for variables, no, they are hygienic [22:37:48] *** Quits: bur_sangjun (bur_sangjun@moz-m669ot.range165-120.btcentralplus.com) (Quit: Leaving) [22:37:53] other stuff (functions, structs, ...) is not hygienic [22:37:57] *** Joins: Gabriel_7 (Gabriel@moz-0e13rm.mtgr.92aj.0e35.2a01.IP) [22:38:00] Ermmm I see. [22:38:28] *** Quits: dinfuehr (dinfuehr@moz-1v6.2no.31.85.IP) (Ping timeout: 121 seconds) [22:38:34] danke [22:38:43] *** Joins: jonmorehouse (jonmorehous@moz-l7c.sbr.3.216.IP) [22:38:44] *** Joins: AlisdairO (anonymous@moz-ntsaoe.cable.virginm.net) [22:38:53] *** Quits: AlisdairO (anonymous@moz-ntsaoe.cable.virginm.net) (Client exited) [22:39:02] *** Joins: brendan (brendaneich@moz-at1.olj.134.64.IP) [22:39:26] *** Joins: jviereck (Adium@moz-e719ch.dip0.t-ipconnect.de) [22:40:08] *** Quits: kkus (kkus@moz-7u2hvh.fios.verizon.net) (Connection closed) [22:40:48] *** Quits: brianloveswords (brianlovesw@moz-n4t7m6.biz.rr.com) (Connection closed) [22:40:49] feti: If you declare a macro within a scope, it can access names in that scope. e.g. fn foo(local_foo: &Foo) { macro_rules! use_local_foo { ... } } [22:41:40] *** Joins: goldenbadger (GoldenBadge@moz-i7uquf.redbrick.dcu.ie) [22:41:54] That's not a terrible idea is it? [22:42:55] *** Joins: Defaultti (Defaultti@moz-bmdn13.kapsi.fi) [22:43:03] As long as you only need the macro within that one function, it's not terrible at all. I've done it that way at least once. [22:43:12] *** Joins: erikj (erikj@moz-aj5go8.jki.re) [22:43:48] Ok cool. Thanks. [22:44:01] Is there a solution to the 'macro ignores expansion' since I'm not passing anything into the macro? [22:44:08] It's pointing to the outer variable I'm accessing. [22:44:08] *** Quits: junqed (junqed@moz-9pe.2ap.70.178.IP) (A TLS packet with unexpected length was received.) [22:44:19] *** Quits: mpark (mpark@moz-hud.3ra.116.199.IP) (Quit: My Mac has gone to sleep. ZZZzzz…) [22:44:32] 'macro expansion ignores token 'var' [22:45:17] that error usually means something entirely different from what it says [22:45:20] can you show the macro? [22:45:38] *** Quits: tkellen (tkellen@moz-o7jjhb.vt.comcast.net) (Client exited) [22:45:56] Yup [22:46:46] *** Quits: lizardo (lizardo@moz-s7l9vj.indt.org.br) (Ping timeout: 121 seconds) [22:47:24] http://pastebin.com/SzNE0BS8 [22:47:32] *** Joins: cimes (cimes@moz-9e6.16c.135.128.IP) [22:47:39] *** Quits: stoner (stoner@moz-d8863v.redhat.com) (Ping timeout: 121 seconds) [22:47:53] One rust forum post suggests I wrap the entire thing in a block. hmm [22:48:18] if you're calling it in a context that expects a single expression, then it'll have to be wrapped in a block [22:48:19] *** Quits: chris_99 (chris_99@moz-g2jhk1.clients.your-server.de) (Connection closed) [22:48:28] the macro itself looks fine [22:48:28] *** Joins: urodna (urodna@moz-9vepd9.res.rr.com) [22:48:30] so how do you call it? [22:48:39] *** Joins: mmalone (mmalone@moz-adr.u03.49.209.IP) [22:48:39] Just token!() [22:48:40] *** Joins: chc4 (chc4@moz-9o2bj2.res.rr.com) [22:48:49] a bit more context please :) [22:49:16] is it ok to use mspc::channel for non-threaded purposes? [22:49:18] Sorry, I'm inside a loop. Above the loop are vars: token, stream, stream_index. I'll post a few lines. [22:49:33] *** Quits: jviereck (Adium@moz-e719ch.dip0.t-ipconnect.de) (Quit: Leaving.) [22:49:34] *** Joins: brianloveswords (brianlovesw@moz-n4t7m6.biz.rr.com) [22:49:36] Yes, wrapping the body in a block is necessary. () => { { ... } } [22:50:02] macros can expand to multiple statements, it just depends on the context [22:50:42] *** Joins: Donkey__ (Donkey@moz-8t57n8.dyn.optonline.net) [22:50:44] this is why i always write macros like () => ( ... ); personally [22:50:59] writing them like () => { } gives you the false impression that it's expanding to a block, but it isn't [22:51:00] Ahhhh that did fix it. Interesting. [22:51:09] Murarth / durka42: Appreciate it. [22:51:30] niconii: Also () for the macro block too right? ( () => (); ) [22:51:37] I've seen that as well, was curious about it. [22:51:46] well, no, i tend to use { } for that [22:51:52] macro_rules! foo { () => (); } [22:52:02] k [22:52:11] clearly [] is the best [22:52:22] *** Quits: Donkey__ (Donkey@moz-8t57n8.dyn.optonline.net) (Connection closed) [22:52:45] *** Quits: Shibe (Shibe@moz-00a.qn1.47.39.IP) (A TLS packet with unexpected length was received.) [22:53:05] *** Quits: Donkey_ (Donkey@moz-egs006.dyn.optonline.net) (Ping timeout: 121 seconds) [22:53:09] i kinda wish the whole "()/[]/{} are interchangable for macros" thing didn't apply to macro_rules! itself :( [22:53:22] *** Joins: dpc (dpc@moz-j55hov.ahkg.bqct.0647.2601.IP) [22:53:33] *** Quits: aidanhs (aidanhs@moz-417.5v2.4.81.IP) (Ping timeout: 121 seconds) [22:53:40] darkstalker: it should work, but if you just want a single-threaded queue, consider VecDeque [22:53:53] you can even use [] on the left side of the => [22:54:07] `macro_rules! foo [[]=>[]];` compiles and it's just kinda... [22:54:26] *** Quits: dwins (dwins@moz-9kg4ko.va.comcast.net) (A TLS packet with unexpected length was received.) [22:54:37] *** Quits: Diggsey (uid120933@moz-ob9ou8.brockwell.irccloud.com) (Quit: Connection closed for inactivity) [22:54:45] kmc, totally forgot about that [22:55:00] *** Quits: stelarcf_ (stelarcf@moz-3gh.lb8.81.92.IP) (Client exited) [22:55:34] the reference even defines "tt" as "either side of the => in macro rules" which is possibly the worst definition I've heard :) [22:55:39] *** Joins: Donkey_ (Donkey@moz-egs006.dyn.optonline.net) [22:55:53] *** Joins: aidanhs (aidanhs@moz-417.5v2.4.81.IP) [22:56:00] *** Quits: nokaa (nokaa@moz-o3h5nt.cloud.scaleway.com) (Quit: Bai Bai!) [22:56:06] *** Joins: nokaa (nokaa@moz-o3h5nt.cloud.scaleway.com) [22:56:27] *** Joins: ob (ob@moz-db2l7g.ca.comcast.net) [22:56:45] *** Quits: UberLambda (uber@moz-c7o.hn7.36.94.IP) (Quit: GTG) [22:57:03] *** Quits: ob (ob@moz-db2l7g.ca.comcast.net) (Quit: Textual IRC Client: www.textualapp.com) [22:58:10] *** Quits: iiddnn_ (iacopodeeno@moz-j3t.57d.233.95.IP) (Client exited) [22:58:57] *** Joins: crunchiebones (jy@moz-5uf.jl4.74.188.IP) [22:59:12] *** Quits: solidsnack (solidsnack@moz-kro69u.ca.comcast.net) (Quit: My Mac has gone to sleep. ZZZzzz…) [22:59:29] *** Quits: Douman (Douman@moz-elh3s6.dynamic.mts-nn.ru) (Quit: ) [23:00:28] *** Joins: FrozenCow (FrozenCow@moz-i2tvv4.chello.nl) [23:00:51] *** Joins: ArturoVM (ArturoVM@moz-ir1crh.prod-infinitum.com.mx) [23:00:56] *** Joins: amyers (amyers@moz-osiar4.md.comcast.net) [23:02:01] *** Joins: ubsan__ (ubsan@moz-cc6.3fu.114.66.IP) [23:02:09] *** Quits: brianloveswords (brianlovesw@moz-n4t7m6.biz.rr.com) (Connection closed) [23:02:21] *** Joins: lidavidm (lidavidm@moz-45t74f.cit.cornell.edu) [23:02:26] Hello (: I'm fairly new to Rust, and I have a question about the type system, and was hoping to get some guidance. [23:02:57] hello! [23:02:58] *** Joins: solidsnack (solidsnack@moz-kro69u.ca.comcast.net) [23:03:07] I'm writing a program which uses some concurrency, and I'm using channels to pass data between threads. [23:04:18] *** Quits: Alek (textual@moz-hivpjb.bb.online.no) (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) [23:04:19] The system has a few different modules (in the abstract sense; nothing to do with the Rust module system), and each module can emit its own type of events. [23:04:29] *** Quits: lutter1 (lutter@moz-7v7ueu.PUBLIC.monkeybrains.net) (Ping timeout: 121 seconds) [23:05:00] *** nikkibee is now known as nikkibee|away [23:05:11] *** Quits: rovar (rovar@moz-6iq.47m.88.38.IP) (Quit: Leaving) [23:05:15] *** Joins: ubsan___ (ubsan@moz-cc6.3fu.114.66.IP) [23:05:56] Since I want every module to be able to receive every type of event, and just ignore the ones it's not interested in, I thought I could use generics, but I'm not sure that's the best approach. [23:06:08] *** Quits: skeet70 (skeet70@moz-evm.d9f.15.71.IP) (Quit: My Mac has gone to sleep. ZZZzzz…) [23:06:42] Sounds like an excellent place to use an enum. [23:06:52] *** Joins: badon_ (badon@moz-n0u.2ql.244.104.IP) [23:06:52] Judging by what you've said, at least. [23:06:57] At first I tried writing a simple enum `Event` type, which has other enum types nested within, but this makes pattern matching quite verbose. [23:07:02] *** Joins: chris_99 (chris_99@moz-g2jhk1.clients.your-server.de) [23:07:29] *** Quits: ubsan__ (ubsan@moz-cc6.3fu.114.66.IP) (Ping timeout: 121 seconds) [23:08:23] *** Quits: Donkey_ (Donkey@moz-egs006.dyn.optonline.net) (Connection closed) [23:08:27] you can match nested enums in a single match too [23:08:45] Then I tried writing an Event trait with an empty body, and `impl`ing it for each specific enum, and then using generic types with type bounds. But that makes matching against specific enum types impossible (?), unless I'm missing something. [23:09:07] *** Quits: laumann (thomas@moz-s86j9i.0.fullrate.ninja) (Ping timeout: 121 seconds) [23:09:12] darkstalker: Yeah, I did that. But I just want to know if there's a more idiomatic way, or if there's a way to better exploit the type system. [23:09:23] *** Quits: ubsan___ (ubsan@moz-cc6.3fu.114.66.IP) (Ping timeout: 121 seconds) [23:09:29] *** Quits: badon (badon@moz-e5d.2ql.244.104.IP) (Ping timeout: 121 seconds) [23:09:48] ArturoVM: You could have an EventListener trait with methods like "handle_foo_event(&self, FooEvent); handle_bar_event(&self, BarEvent); ..." [23:09:55] *** Quits: kazagistar (Adium@moz-3iu.rs2.191.76.IP) (Quit: Leaving.) [23:09:57] ArturoVM: And the trait could provide empty default implementations of each method [23:10:20] ArturoVM: And then each module could `impl EventListener" and just provide handlers for the event types it cares about [23:10:41] *** Joins: laumann (thomas@moz-s86j9i.0.fullrate.ninja) [23:10:53] *** Quits: dfockler (dan@moz-rm6ima.wa.comcast.net) (Ping timeout: 121 seconds) [23:11:09] *** badon_ is now known as badon [23:11:15] *** Quits: awal (awal@moz-vmu.a4l.98.14.IP) (Quit: leaving) [23:11:23] *** Quits: jonmorehouse (jonmorehous@moz-l7c.sbr.3.216.IP) (Connection closed) [23:11:33] *** Joins: jonmoreh1 (jonmorehous@moz-l7c.sbr.3.216.IP) [23:12:08] *** Quits: TimNN (TimNN@moz-r8l.9ss.89.141.IP) (Quit: My Mac has gone to sleep. ZZZzzz…) [23:12:09] mbrubeck: That's an interesting suggestion. And then just call every method in the trait for each module? [23:12:22] *** Joins: gopar (gopar@moz-5039uj.ca.comcast.net) [23:12:39] *** Joins: kerrang (kerrang@moz-8ka5mh.fios.verizon.net) [23:13:28] I'm still figuring out visibility. Is there a way to make a field visible to submodules but not to parent modules? [23:14:24] *** Parts: kerrang (kerrang@moz-8ka5mh.fios.verizon.net) () [23:14:49] lilred: yes; private things are visible to submodules [23:15:11] kmc: thanks <3 [23:15:17] *** Joins: aatch (james@moz-rat.omt.54.210.IP) [23:15:28] *** Quits: slester (slester@moz-f33uhg.7nqd.tocq.e000.2605.IP) (Quit: Leaving...) [23:16:03] *** Quits: peteyg (peteyg@moz-e7m.qu3.210.98.IP) (Ping timeout: 121 seconds) [23:16:32] *** Joins: TimNN (TimNN@moz-r8l.9ss.89.141.IP) [23:16:48] *** Joins: ryanlevick (ryanlevick@moz-g2l6og.dip0.t-ipconnect.de) [23:17:06] *** Quits: kmicu (kmicu@moz-uga.edn.218.91.IP) (Client exited) [23:17:58] Does anyone have any updates on the state of raft-rs or more generally the state of a raft implementation in Rust? Maybe dcb knows? [23:18:07] hoverbear: ^ ? [23:18:33] anyone have a bash one-liner for checking if rustc is stable? [23:18:46] 'multirust run stable' ;) [23:18:49] ryanlevick: it's not complete, but we neither myself or hoverbear has had much time to work on it [23:18:56] steveklabnik: assuming no multirust unfortunately [23:19:00] i figured :) [23:19:07] ryanlevick: there is a #raft channel you can jump in, I can answer any questions [23:19:13] *** Quits: JagaJaga (JagaJaga@moz-ua8.hhl.62.178.IP) (Ping timeout: 121 seconds) [23:19:16] best practices question: I have a datatype Foo, and a function destroy: Foo -> (). Is there no way to use destroy() to implement drop? [23:19:20] trying to make a travis setup similar to https://github.com/japaric/rust-everywhere [23:19:31] dcb: cool! I will jump there [23:19:35] reem: how about rustc -V | grep stable [23:19:43] lilred: correct [23:19:53] lilred: it would make more sense to use drop to implement destroy [23:19:59] in the simplest case destroy would be an empty function [23:20:02] oh it doesn't actually say stable in there :/ [23:20:15] playbot-veno, VERSION [23:20:15] -playbot-veno- "rustc 1.6.0 (c30b771ad 2016-01-19)" [23:20:20] yeah beta and nightly say beta and nightly [23:20:23] but stable just says nothing [23:20:26] which is how mem::drop (the free function, not the trait method) is implemented [23:20:27] --vverbose? [23:20:35] *** Joins: lutter1 (lutter@moz-7v7ueu.PUBLIC.monkeybrains.net) [23:20:40] reem, check for not-{beta, nightly, dev}? [23:20:43] oh it's not that anymore [23:20:44] hmm [23:20:45] *** Joins: Donkey_ (Donkey@moz-egs006.dyn.optonline.net) [23:21:02] `rustc_version` uses the semver parser and looks for the `prerelease` tag (as in "x.y.z-prerelease") [23:21:21] Stable just has "x.y.z" with no "-foo" [23:21:54] I could check for rustc —version | grep nightly and rustc —version | grep beta but it’s a bit verbose [23:22:20] Don't forget "dev" [23:22:24] *** Joins: ansible1 (kvirc@moz-ks4ued.co.comcast.net) [23:22:29] rustc -V | grep -v '\(beta\|nightly\|dev\)' [23:22:39] *** Quits: blackgoat (blackgoat@moz-stj.iu0.157.221.IP) (Quit: WeeChat 1.4) [23:22:47] my rustc version is `1.8.0-dev` [23:22:49] *** Joins: Kingsquee (kingsley@moz-3oducq.bchsia.telus.net) [23:22:54] *** Quits: nicholasf (nicholasf@moz-5hgefo.internode.on.net) (Quit: Leaving...) [23:22:58] *** Joins: dzbarsky (Adium@moz-v18mcd.ca.comcast.net) [23:24:06] ah, yes [23:24:11] also, when I have nested submodules inside one file, is there a way for the submodules to inherit the scope of the parent module? (i.e. see everything that's also in scope in the parent module without "use") [23:25:18] Is there a cargo command for try to compile a binary but don’t run it? [23:25:29] reem: cargo build [23:25:35] cargo build --bin [23:25:58] nice thanks [23:26:05] match root.take() { None => None, Some(node) => { root = node.right; Some(node.x) } how can I do this ? [23:26:16] how does cargo test work if I pass —target? [23:26:25] i want to mutate root to node.right. but return node.x [23:27:01] *** Quits: dzbarsky (Adium@moz-v18mcd.ca.comcast.net) (Ping timeout: 121 seconds) [23:27:28] *** Quits: samx (sami@moz-oq8dni.dyn.optonline.net) (Quit: My Mac has gone to sleep. ZZZzzz…) [23:27:45] root = node.right; seems to move entire node, not just node.right. so i can't return node.x [23:28:26] Thanks mbrubeck, btw :) [23:28:27] saml: Some(Node { right, x, .. }) => { root = right; Some(x) } [23:29:13] *** Joins: ubsan__ (ubsan@moz-cc6.3fu.114.66.IP) [23:29:19] ArturoVM: Oh, you're welcome! Sorry I missed your follow-up question above, but it looks like you understood my suggestion correctly [23:29:34] *** Joins: vadix_ (vadix@moz-jmj.0nm.219.24.IP) [23:29:43] So, a more concrete question: is there a way to define a concrete type destructuring in a match branch against a generic type var? [23:29:53] mbrubeck: no worries (: [23:29:57] *** Joins: brianloveswords (brianlovesw@moz-n4t7m6.biz.rr.com) [23:29:58] *** Quits: pastoraleman (pastoralema@moz-8ih0dv.cable.virginm.net) (Quit: My Mac has gone to sleep. ZZZzzz…) [23:30:47] ArturoVM: No, pretty much the only thing you can do with a value of generic type is call methods of any traits that the generic type is bounded on [23:31:42] mbrubeck, thanks. node is Box though [23:32:29] saml: ah, then maybe inside the match body do `let Node { right, x, .. } = *node; root = right; ...` [23:32:44] until box patterns are stable :) [23:32:52] ah that makes sense [23:33:17] *** Quits: ubsan__ (ubsan@moz-cc6.3fu.114.66.IP) (Ping timeout: 121 seconds) [23:34:15] anyone know if I can use homu.io with a private repo? [23:34:18] *** Quits: futile (felix@moz-cursjl.unity-media.net) (Ping timeout: 121 seconds) [23:35:19] *** Joins: dinfuehr (dinfuehr@moz-1v6.2no.31.85.IP) [23:35:21] i'm using rust stable. let Node {right, v, ..} = *node; this says by the time v is assigned, node is already moved [23:35:49] hmm [23:36:00] And actually, I realized that if that worked, then your original code should have worked too [23:36:35] reem - I doubt that, it only requests access to public repositories from GH. [23:36:44] *** bholley_away is now known as bholley [23:36:51] The Debug trait is not implemented for [u8: N]? o_O [23:37:05] lilred: only for N <=32 [23:37:12] steveklabnik: I see, thanks! [23:37:22] need type level integers [23:37:22] reem - "You don't have permission on this repository" when trying to use it on a private one. [23:37:48] saml: yeah, let Foo { just_one_field, .. } = foo; is probably just a move of all of foo [23:38:09] repro of saml's error http://is.gd/WEcJgN [23:38:10] particularly if it's actually *box_of_foo [23:38:34] mbrubeck: thanks again [23:38:43] oh, hmm, mbrubeck's should work though, yeah [23:38:51] This looks like the same problem with slice patterns that bluss (I think) was noticing earlier [23:38:58] *** Joins: tm (tm@moz-j3ht7j.dynamic.chello.pl) [23:39:01] or similar [23:39:09] *** Quits: brianloveswords (brianlovesw@moz-n4t7m6.biz.rr.com) (Quit: My Mac has gone to sleep. ZZZzzz…) [23:39:14] let node = *node; let Node { } = node; works [23:39:16] how do you run rust? these things aren't in book [23:39:20] learn [23:39:22] *** Quits: dinfuehr (dinfuehr@moz-1v6.2no.31.85.IP) (Ping timeout: 121 seconds) [23:39:27] this sounds like a bug [23:39:33] or at very least something that should be considered one [23:39:34] steveklabnik: It'd be nice if something could be done about tuples as well. I feel like that'd need the ability to prove by induction - here's how to do it for a tuple of length 1, here's how to do it for a tuple of length n+1 given a tuple of length n, type checker does the rest. [23:39:45] Ketsuban: it's the same exact thing, need typ-level integers [23:39:45] *** Joins: brianloveswords (brianlovesw@moz-n4t7m6.biz.rr.com) [23:40:17] what's let node = *node; ? shadowing? [23:40:19] *** Joins: slester (slester@moz-28gr00.res.rr.com) [23:40:26] yeah [23:40:36] other things that work include {*node} (ie, make it an lvalue) [23:40:43] so there's some weird special-casing going on that's broken [23:40:54] talchas, saml: Looks like https://github.com/rust-lang/rust/issues/30564 [23:41:08] http://is.gd/1tf3Ra wow that works for real [23:42:08] *** Joins: samx (sami@moz-oq8dni.dyn.optonline.net) [23:42:42] *** Quits: lambdanon (lambdanon@moz-9p3lhv.dip0.t-ipconnect.de) (Connection closed) [23:42:45] *** Quits: lidavidm (lidavidm@moz-45t74f.cit.cornell.edu) (Ping timeout: 121 seconds) [23:42:52] that shadowing is a good trick. now my project compiles [23:44:17] *** Joins: iqualfragile (iqualfragil@moz-oof4qc.h4nc.5h6m.810a.2a02.IP) [23:44:21] *** Quits: will_sm (will-medran@moz-09s.dbi.142.75.IP) (Quit: Leaving) [23:44:44] *** Joins: ubsan__ (ubsan@moz-cc6.3fu.114.66.IP) [23:44:48] tilpner: makes sense, thanks for checking [23:44:57] this repo should be public soon anyway :) [23:45:08] yay, more public repos [23:45:29] reem - You could maybe run your own homu, but... that's probably more effort than it's worth, if you only use it for one repo. [23:45:45] yeah I’d rather just use travis for now and use homu when it becomes public [23:46:09] *** Quits: saml (saml@moz-0pt9vd.cst.lightpath.net) (Quit: Leaving) [23:46:16] *** Quits: FrozenCow (FrozenCow@moz-i2tvv4.chello.nl) (Quit: Leaving) [23:47:30] *** Joins: futile (felix@moz-cursjl.unity-media.net) [23:48:06] *** Quits: tromey (tromey@moz-s93niv.hlrn.qwest.net) (Quit: ERC (IRC client for Emacs 25.0.90.1)) [23:48:38] *** Joins: mpark (mpark@moz-obt.j7d.161.12.IP) [23:48:55] *** Quits: ubsan__ (ubsan@moz-cc6.3fu.114.66.IP) (Ping timeout: 121 seconds) [23:49:06] *** Quits: orks (orks@moz-t1r.tom.44.37.IP) (Connection closed) [23:49:33] *** Joins: infynyxx (infynyxx@moz-nh1qrt.nj.comcast.net) [23:50:28] ok, so i tried turning an originally recursive function into an iterative one and i have tons and tons of problems. this is my result after about 4 hours of trying, and im starting to doubt my sanity. The function needs to read the current object, destructure it, change parts of its contents and then set a new current object, which is saved in one of the fields of the object. [23:50:49] *** Joins: Zorg (Zorg@moz-fknvkg.pa.comcast.net) [23:51:18] i seem to have for some reason just gotten it right [23:51:22] just in this second [23:51:24] -.- [23:51:44] \o/ [23:51:49] IRC: it works [23:52:02] *** bholley is now known as bholley_away [23:52:03] *** Joins: mib_0ldzbe (Mibbit@moz-3ov.3db.236.192.IP) [23:52:05] *** Joins: ubsan__ (ubsan@moz-cqobc9.u57p.d4fs.fb90.2607.IP) [23:52:52] I'm trying to get rust to build via CI on Gitlab. I'm attempting to install rust using rustup in the CI YAML. Rustup takes input (y/n). Is there a way to auto accept? [23:53:28] how does cargo bench work? [23:53:36] does it keep stuff in memory? [23:53:37] mib_0ldzbe: --yes [23:53:45] cause i run a benchmark, and it uses 8 gig ram [23:53:53] mbrubeck: thanks [23:53:58] and i don't see where that could ever be acumulated in my code [23:54:01] *** Quits: ubsan_ (ubsan@moz-cc6.3fu.114.66.IP) (Ping timeout: 121 seconds) [23:54:10] *** Quits: brianloveswords (brianlovesw@moz-n4t7m6.biz.rr.com) (Connection closed) [23:54:55] *** Joins: brianloveswords (brianlovesw@moz-n4t7m6.biz.rr.com) [23:55:09] great, the iterative version is even slower then the recursive one [23:55:16] and it does not seem to save ram, as i hoped [23:55:18] argh [23:55:21] 4 hours wasted [23:56:29] *** Joins: Morten (Morten@moz-ltrurg.bb.online.no) [23:57:19] *** Joins: fyolnish (fyolnish@moz-8tfsb3.so-net.ne.jp) [23:57:25] bench shouldn't be using a ton of ram on its own [23:57:58] *** Quits: brianloveswords (brianlovesw@moz-n4t7m6.biz.rr.com) (Connection closed) [23:57:59] if you've got some global vec or something and you push into it on every benchmark iteration though, that could get bad [23:58:23] yeah, i ran cargo bench probably like ~3500 times in the course of a few days and it never used more than a couple hundred megs [23:58:31] *** Joins: brianloveswords (brianlovesw@moz-n4t7m6.biz.rr.com) [23:58:45] (where by global I mean even just outside of the .iter() call possibly) [23:58:48] *** Quits: brianloveswords (brianlovesw@moz-n4t7m6.biz.rr.com) (Quit: My Mac has gone to sleep. ZZZzzz…) [23:59:27] *** Quits: adhoc (adhoc@moz-579fgj.internode.on.net) (Ping timeout: 121 seconds) [23:59:41] *** Quits: ff (flaper87Moz@moz-ql4.mp2.101.148.IP) (Quit: 1.4) [23:59:45] since you don't control how many times the closure is called, that results in a bad benchmark too [23:59:56] since the size of the data structure varies without control