| --- Log opened Wed Dec 29 00:00:51 2021 |
| 00:28 | <&[R]> | I love how git hooks receive critical information via stdin |
| 00:28 | <&[R]> | Makes scripting so easy /s |
| 01:13 | | Degi_ [Degi@Nightstar-c129ic.pool.telefonica.de] has joined #code |
| 01:16 | | Degi [Degi@Nightstar-rgcgoi.pool.telefonica.de] has quit [Ping timeout: 121 seconds] |
| 01:16 | | Degi_ is now known as Degi |
| 01:47 | | abudhabi_ [abudhabi@Nightstar-0oftkk.adsl.tpnet.pl] has joined #code |
| 01:48 | | abudhabi__ [abudhabi@Nightstar-ffjad2.adsl.tpnet.pl] has quit [Ping timeout: 121 seconds] |
| 01:50 | | gizmore [kvirc@Nightstar-ech4la.dip0.t-ipconnect.de] has joined #code |
| 01:53 | | gizmore|2 [kvirc@Nightstar-ak4qns.dip0.t-ipconnect.de] has quit [Ping timeout: 121 seconds] |
| 04:13 | | McMartin [mcmartin@Nightstar-i80eaa.ca.comcast.net] has quit [[NS] Quit: Reboot] |
| 04:17 | | McMartin [mcmartin@Nightstar-i80eaa.ca.comcast.net] has joined #code |
| 04:17 | | mode/#code [+ao McMartin McMartin] by ChanServ |
| 05:16 | | Vorntastic [uid293981@Nightstar-phvupn.irccloud.com] has joined #code |
| 05:16 | | mode/#code [+qo Vorntastic Vorntastic] by ChanServ |
| 10:19 | | gnolam [quassel@Nightstar-1m0jkg.cust.bahnhof.se] has quit [[NS] Quit: Gone] |
| 11:18 | | gnolam [quassel@Nightstar-0oc.n80.224.185.IP] has joined #code |
| 11:18 | | mode/#code [+o gnolam] by ChanServ |
| 12:01 | | catalyst_ is now known as catalyst |
| 13:19 | | gnolam [quassel@Nightstar-0oc.n80.224.185.IP] has quit [[NS] Quit: Switching trains] |
| 14:13 | | gnolam [quassel@Nightstar-9o3.n80.224.185.IP] has joined #code |
| 14:13 | | mode/#code [+o gnolam] by ChanServ |
| 14:47 | | gnolam [quassel@Nightstar-9o3.n80.224.185.IP] has quit [[NS] Quit: http://quassel-irc.org - Chat comfortably. Anywhere.] |
| 15:01 | | Vornicus [Vorn@ServerAdministrator.Nightstar.Net] has joined #code |
| 15:01 | | mode/#code [+qo Vornicus Vornicus] by ChanServ |
| 15:25 | | gnolam [lenin@Nightstar-j9ajs0.priv.bahnhof.se] has joined #code |
| 15:25 | | mode/#code [+o gnolam] by ChanServ |
| 17:04 | | Vorntastic [uid293981@Nightstar-phvupn.irccloud.com] has quit [[NS] Quit: Connection closed for inactivity] |
| 17:04 | | catalyst_ [catalyst@Nightstar-seklp3.dab.02.net] has joined #code |
| 17:06 | | catalyst [catalyst@Nightstar-ejd4sd.cable.virginm.net] has quit [Ping timeout: 121 seconds] |
| 17:54 | | catalyst [catalyst@Nightstar-ejd4sd.cable.virginm.net] has joined #code |
| 17:56 | | catalys51 [catalyst@Nightstar-ejd4sd.cable.virginm.net] has joined #code |
| 17:56 | | catalyst [catalyst@Nightstar-ejd4sd.cable.virginm.net] has quit [Connection reset by peer] |
| 17:58 | | catalyst_ [catalyst@Nightstar-seklp3.dab.02.net] has quit [Connection reset by peer] |
| 18:05 | | catalys51 [catalyst@Nightstar-ejd4sd.cable.virginm.net] has quit [Connection closed] |
| 18:07 | | catalyst [catalyst@Nightstar-ejd4sd.cable.virginm.net] has joined #code |
| 18:28 | | Emmy [Emmy@Nightstar-l49opt.fixed.kpn.net] has joined #code |
| 19:56 | | Kindamoody[zZz] is now known as Kindamoody |
| 20:07 | <&McMartin> | Ah, Rust |
| 20:07 | <&McMartin> | Static monomorphization is all fun and games until your function has a potential return type of Filter<Flatten<Map<Flatten<Map<Flatten<Map<Flatten<Map<Flatten<Map<std::vec::IntoIter<MyActualType>>>>>>>>>>>> |
| 20:09 | <&McMartin> | Fortunately this function was only called from one place, so I can inline it. |
| 20:16 | <&McMartin> | (Which is also good because calling collect() before that function returned introduces a 10x slowdown!) |
| 20:23 | <~Vornicus> | what the hell are you doing |
| 20:34 | < abudhabi_> | Flattening maps. |
| 20:36 | <&McMartin> | chaining a lot of calls of map(), flatten(), and filter(). |
| 20:37 | <&McMartin> | And since it's strongly typed all the way down, every call to map or filter or reduce or flatten or whatever yields a new type that takes the previous type as its type argument. |
| 20:38 | <&McMartin> | There's not really such a thing as "returns an object of unknown type but it implements this API" in Rust. The closest you get is "returns a freshly heap-allocated pointer to same", which is usually not what you'd want. |
| 20:40 | <&McMartin> | I suspect the reason that there's such a dramatic speedup is that the flattening operation never actually *happens to a data structure* in the resulting code |
| 20:40 | <&McMartin> | Instead it's basically setting up a tree-like data structure at compile-time and then it fills it in and traverses it at runtime. |
| 20:45 | <&McMartin> | Also I'm... not sure if there's an easier way to do this |
| 20:45 | <&McMartin> | But I turned a Vec<Option<T>> into a Vec<T> via v.map(|c| c.into_iter()).flatten().collect() |
| 20:45 | <~Vornicus> | what's flatten do |
| 20:45 | <~Vornicus> | ...that does look like something that should be easier to do |
| 20:46 | <&McMartin> | flatten, when applied to arrays, turns [[1, 2], [3, 4], [5]] into [1, 2, 3, 4, 5] |
| 20:46 | <&McMartin> | So for an iterator of iterators, it does something similar. |
| 20:46 | <~Vornicus> | ...that is a lot of fucking flattens what are you *doing* |
| 20:46 | <&McMartin> | Day 22b in AoC this year~ |
| 20:47 | <&McMartin> | I have an operation that divides objects into halves, and I want to do this up to 6 times, and the divided objects need to each be divided by later steps. |
| 20:47 | <~Vornicus> | oh I see |
| 20:48 | <&McMartin> | I have just been informed that there's a flat_map() method that combines the map() and flatten() calls. |
| 20:55 | <&McMartin> | and "there should be an easier way"... filter_map is the easier way |
| 21:21 | <~Vornicus> | theremustbeabetterway.gif |
| 21:23 | | catalyst_ [catalyst@Nightstar-ejd4sd.cable.virginm.net] has joined #code |
| 21:23 | | catalyst [catalyst@Nightstar-ejd4sd.cable.virginm.net] has quit [Connection reset by peer] |
| 22:02 | <&Reiver> | McMartin: In fairness, I am all too often getting similar strings in MSQL when trying to do type conversions >_> |
| 22:13 | | Vornicus [Vorn@ServerAdministrator.Nightstar.Net] has quit [Connection closed] |
| 23:01 | | Emmy [Emmy@Nightstar-l49opt.fixed.kpn.net] has quit [Ping timeout: 121 seconds] |
| 23:18 | <&McMartin> | As for the better way... the functional programming guys are potentially wrong and maybe big chains of map/reduce statements *aren't* so much the way to go for data sets that fit in the RAM of a single process~ |
| 23:18 | <&McMartin> | Rewriting it in C with a single, brain-dead, mutable linked list would be a fun comparison. |
| 23:19 | <&McMartin> | But... the map/reduce version is running in 650ms now which is generally Good Enough For Me |
| 23:49 | | abudhabi__ [abudhabi@Nightstar-9b2kpb.adsl.tpnet.pl] has joined #code |
| 23:50 | | abudhabi_ [abudhabi@Nightstar-0oftkk.adsl.tpnet.pl] has quit [Ping timeout: 121 seconds] |
| --- Log closed Thu Dec 30 00:00:52 2021 |