Logs: liberachat/#haskell
| 2021-05-28 14:59:44 | <maerwald> | if you can answer to me what a patch in darcs is in one simple sentence... |
| 2021-05-28 15:00:06 | <maerwald> | so 80% of users will never grok what it is |
| 2021-05-28 15:00:12 | <siers> | how do I withStrategy (parList rseq) . map f, but with traverse instead of map? |
| 2021-05-28 15:00:17 | → | winter joins (~winter@2603-6011-f901-9e5b-0000-0000-0000-08cf.res6.spectrum.com) |
| 2021-05-28 15:00:39 | × | haskman quits (~haskman@106.201.28.184) (Quit: Going to sleep. ZZZzzz…) |
| 2021-05-28 15:00:47 | <jrm> | Hafydd: Fairly confident the answer is 'yes'. |
| 2021-05-28 15:01:33 | <Hafydd> | I think GHC was fairly Fat the last time I tried compiling or (or, indeed, installing a pre-made binary), so that would be impressive. |
| 2021-05-28 15:02:08 | <cdsmith> | siers: I'm not sure that makes sense. mapM cannot be parallelized, in general. |
| 2021-05-28 15:02:13 | <cdsmith> | I mean, traverse. Same thing |
| 2021-05-28 15:03:38 | <sciencentistguy> | i don't think i've ever compiled GHC myself, but compiling haskell-language-server took an age on my (pretty powerful) desktop so i can't imaging GHC is much better |
| 2021-05-28 15:03:47 | → | doublex joins (~doublex@2601:542:c480:6ee0:84eb:7213:de16:e82e) |
| 2021-05-28 15:04:16 | ← | siers parts (~ij@user/ij) (WeeChat 2.9) |
| 2021-05-28 15:04:20 | → | siers joins (~ij@user/ij) |
| 2021-05-28 15:04:28 | × | immibis quits (~immibis@62.156.144.218) (Remote host closed the connection) |
| 2021-05-28 15:04:35 | <siers> | cdsmith, well, surely it can |
| 2021-05-28 15:05:11 | <boxscape> | presumably you can parallelize the map part but not the M part? |
| 2021-05-28 15:05:27 | <boxscape> | (in general) |
| 2021-05-28 15:05:32 | <enikar> | monadlight: I loved reading this book. |
| 2021-05-28 15:05:34 | × | lortabac quits (~lortabac@2a01:e0a:541:b8f0:fdcc:9f0a:2fc4:5c69) (Quit: WeeChat 2.8) |
| 2021-05-28 15:05:54 | × | sondre quits (~sondrelun@eduroam-193-157-188-96.wlan.uio.no) (Ping timeout: 265 seconds) |
| 2021-05-28 15:06:03 | × | aman quits (~lpyfist@user/aman) (Quit: aman) |
| 2021-05-28 15:06:32 | <siers> | I guess parallel package is for pure stuff. parallel-io has parallel :: [IO a] -> IO [a] |
| 2021-05-28 15:06:58 | × | dunham quits (~dunham@97-113-35-16.tukw.qwest.net) (Ping timeout: 244 seconds) |
| 2021-05-28 15:07:25 | → | _73 joins (~user@pool-96-252-123-136.bstnma.fios.verizon.net) |
| 2021-05-28 15:07:46 | → | haskman joins (~haskman@106.201.28.184) |
| 2021-05-28 15:07:58 | <cdsmith> | siers: Yeah, strategies is for evaluation strategies, which don't affect the result. If you want to run IO actions in parallel, that is a change in the result, so you need to say so. (Other monads, like State, just cannot be performed in parallel at all) |
| 2021-05-28 15:09:13 | <monadlight> | enikar: the way the book explains Monad and Applicative is easier than most other explanation I've read before. |
| 2021-05-28 15:09:19 | → | involans joins (~alex@cpc92718-cmbg20-2-0-cust157.5-4.cable.virginm.net) |
| 2021-05-28 15:09:46 | × | tose quits (~tose@ip-85-160-8-1.eurotel.cz) (Ping timeout: 264 seconds) |
| 2021-05-28 15:10:06 | × | dunj3 quits (~dunj3@2001:16b8:3064:9000:3cac:ae41:dda8:223b) (Ping timeout: 248 seconds) |
| 2021-05-28 15:10:19 | <monadlight> | And the fact that it's ~400 pages long instead of 1400 pages long also help trememously for newbie like me. :-) |
| 2021-05-28 15:11:10 | → | Dynom joins (~niels@80-114-12-206.cable.dynamic.v4.ziggo.nl) |
| 2021-05-28 15:11:12 | → | spirgel joins (spirgel@gateway/vpn/protonvpn/spirgel) |
| 2021-05-28 15:11:42 | × | reumeth quits (~reumeth@2001:4652:9745:0:72c9:4eff:fea7:32ab) (Ping timeout: 248 seconds) |
| 2021-05-28 15:11:54 | → | sondre joins (~sondrelun@eduroam-193-157-188-96.wlan.uio.no) |
| 2021-05-28 15:12:50 | × | img quits (~img@2405:6580:b1c0:2500:6e94:ae4a:a398:5347) (Quit: ZNC 1.8.1 - https://znc.in) |
| 2021-05-28 15:13:11 | → | img joins (~img@2405:6580:b1c0:2500:6e94:ae4a:a398:5347) |
| 2021-05-28 15:13:21 | × | connrs quits (~connrs@s1.connrs.uk) (Quit: ZNC 1.8.2 - https://znc.in) |
| 2021-05-28 15:13:34 | <_73> | I will have list of about 4 billion items that I will be updating using indexes. I will have variables holding integers that represent important indexes and I will be accessing and updating items using offsets from said indexes. I would like to use a immutable data structure. What data structure would you recommend? |
| 2021-05-28 15:13:35 | → | dunham joins (~dunham@97-113-35-16.tukw.qwest.net) |
| 2021-05-28 15:13:42 | <sciencentistguy> | "Haskell programming from first principles" is the best haskell book i've read |
| 2021-05-28 15:14:32 | → | doublex_ joins (~doublex@2601:542:c480:6ee0:a5a3:1270:f9ea:4275) |
| 2021-05-28 15:14:50 | × | doublex_ quits (~doublex@2601:542:c480:6ee0:a5a3:1270:f9ea:4275) (Client Quit) |
| 2021-05-28 15:14:54 | × | spirgel_ quits (spirgel@gateway/vpn/protonvpn/spirgel) (Ping timeout: 248 seconds) |
| 2021-05-28 15:15:08 | <tomsmeding> | _73: MVector (mutable vector) from https://hackage.haskell.org/package/vector-0.12.3.0/docs/Data-Vector-Mutable.html ? |
| 2021-05-28 15:15:29 | <boxscape> | tomsmeding they said "IMmutable" :) |
| 2021-05-28 15:15:40 | <tomsmeding> | facepalm |
| 2021-05-28 15:15:45 | <tomsmeding> | Data.Map |
| 2021-05-28 15:15:50 | <tomsmeding> | or I guess Data.IntMap |
| 2021-05-28 15:16:07 | <enikar> | monadlight: I agree. |
| 2021-05-28 15:16:12 | <merijn> | SQLite :p |
| 2021-05-28 15:16:26 | → | platz joins (~platz@user/platz) |
| 2021-05-28 15:16:32 | × | sondre quits (~sondrelun@eduroam-193-157-188-96.wlan.uio.no) (Ping timeout: 265 seconds) |
| 2021-05-28 15:16:33 | <_73> | ill try a map and see how it goes |
| 2021-05-28 15:16:41 | <siers> | merijn, I like your answer :D |
| 2021-05-28 15:16:56 | <merijn> | The answer is always more SQLite :p |
| 2021-05-28 15:17:03 | <tomsmeding> | though I wonder if you'd be able to do some optimisation of the data structure by knowing that the indices are contiguous |
| 2021-05-28 15:17:11 | <_73> | ya a database is probably the only way to actually be efficient but I am going for simplicity |
| 2021-05-28 15:17:14 | → | ku joins (~ku@2601:280:c780:7ea0:bdb5:230d:40c:e48e) |
| 2021-05-28 15:17:32 | <tomsmeding> | most probably you can save some memory by not storing all the keys redundantly |
| 2021-05-28 15:17:43 | <tomsmeding> | _73: how much data per item |
| 2021-05-28 15:17:50 | → | favonia joins (~favonia@user/favonia) |
| 2021-05-28 15:18:03 | <boxscape> | 4 billion items is quite a bit of RAM |
| 2021-05-28 15:18:07 | <_73> | length 8 BitVectors from Data.BitVector. |
| 2021-05-28 15:18:50 | <tomsmeding> | okay then the overhead from the map is going to be like 16x your data |
| 2021-05-28 15:18:51 | → | stackbeard joins (~stackbear@pool-173-76-99-163.bstnma.fios.verizon.net) |
| 2021-05-28 15:18:54 | <tomsmeding> | if not more |
| 2021-05-28 15:19:36 | → | learner-monad joins (~ehanneken@cpe-174-105-47-100.columbus.res.rr.com) |
| 2021-05-28 15:19:41 | <tomsmeding> | also BitVector itself is not all too space-efficient if I read the definition correctly; it seems to store the bits in an Integer |
| 2021-05-28 15:20:09 | <tomsmeding> | _73: is it worth optimising the memory usage a bit? Or do you have a 128GB machine :p |
| 2021-05-28 15:20:38 | <tomsmeding> | also I would suggest reconsidering the requirement for the data structure to be immutable :p |
| 2021-05-28 15:21:56 | <_73> | it seems that I am going to have to optimise |
| 2021-05-28 15:22:32 | × | involans quits (~alex@cpc92718-cmbg20-2-0-cust157.5-4.cable.virginm.net) (Ping timeout: 252 seconds) |
| 2021-05-28 15:22:55 | <tomsmeding> | well I can think of a data structure that can store this compactly (in, like 4GB, given that there are 4 billion bytes to store) -- a mutable vector :p |
| 2021-05-28 15:23:10 | <tomsmeding> | an immutable vector will not work for updating |
| 2021-05-28 15:23:31 | → | eggplantade joins (~Eggplanta@2600:1700:bef1:5e10:9d49:4665:d75d:fdb) |
| 2021-05-28 15:23:58 | <boxscape> | (not efficiently, anyway :P) |
| 2021-05-28 15:24:16 | × | merijn quits (~merijn@83-160-49-249.ip.xs4all.nl) (Ping timeout: 264 seconds) |
| 2021-05-28 15:24:18 | <tomsmeding> | updating elements of a 4GB immutable vector transcends simple "inefficient" for me |
| 2021-05-28 15:24:34 | × | zmt01 quits (~zmt00@c-24-4-119-97.hsd1.ca.comcast.net) (Changing host) |
| 2021-05-28 15:24:34 | → | zmt01 joins (~zmt00@user/zmt00) |
| 2021-05-28 15:24:42 | zmt01 | is now known as zmt00 |
| 2021-05-28 15:25:28 | → | sondre joins (~sondrelun@eduroam-193-157-188-96.wlan.uio.no) |
| 2021-05-28 15:25:43 | <boxscape> | would MVector s Word8 be the right choice here then? |
| 2021-05-28 15:26:14 | <tomsmeding> | I would say so |
| 2021-05-28 15:26:19 | <_73> | I have never used a mutable data structure before in haskell so I don't know what problems this may cause. I have data type called `ProgramState` that is a record where one of its fields would be the MVector. All of my functions use the state type and are `f :: a -> a -> State ProgramState b`. Is this going to cause problems. |
| 2021-05-28 15:26:32 | <tomsmeding> | hm no, you need unboxed because boxed Word8 is still like 32 bytes |
| 2021-05-28 15:26:34 | → | myShoggoth joins (~myShoggot@97-120-89-117.ptld.qwest.net) |
| 2021-05-28 15:26:39 | <boxscape> | ah, right |
| 2021-05-28 15:26:55 | <tomsmeding> | Data.Vector.Unboxed.Mutable it would be then |
| 2021-05-28 15:27:36 | × | oats quits (~thomas@user/oats) (Quit: until later, my friends) |
| 2021-05-28 15:27:38 | <tomsmeding> | _73: using a mutable vector would require that `f` gets type `f :: a -> a -> IO (State ProgramState b)` if you choose the IO variant |
| 2021-05-28 15:27:54 | <tomsmeding> | you can also use the ST variant, in which case the IO gets replaced with `ST s` |
| 2021-05-28 15:27:58 | → | oats joins (~thomas@user/oats) |
| 2021-05-28 15:28:00 | × | sciencentistguy quits (~sciencent@212.102.63.133) (Quit: WeeChat 3.1) |
| 2021-05-28 15:28:09 | → | sciencentistguy joins (~sciencent@212.102.63.133) |
| 2021-05-28 15:28:13 | × | eggplantade quits (~Eggplanta@2600:1700:bef1:5e10:9d49:4665:d75d:fdb) (Ping timeout: 272 seconds) |
| 2021-05-28 15:28:15 | <tomsmeding> | Using ST is nice in that you don't need to live in IO; there is a function `runST :: (forall s. ST s a) -> a` |
| 2021-05-28 15:28:19 | <cdsmith> | _73: That sort of state-transformer architecture with a mutable structure is dangerous. It would still work as long as you only access the state in a linear way, but if you access old versions of ProgramState, they will still have the latest contents of the vector. |
| 2021-05-28 15:28:43 | <tomsmeding> | cdsmith++ |
All times are in UTC.