Home freenode/#haskell: Logs Calendar

Logs: freenode/#haskell

←Prev  Next→
Page 1 .. 349 350 351 352 353 354 355 356 357 358 359 .. 5022
— 502,152 events total
2020-10-01 15:07:18 × Lord_of_Life quits (~Lord@unaffiliated/lord-of-life/x-0885362) (Ping timeout: 272 seconds)
2020-10-01 15:08:13 Lord_of_Life_ is now known as Lord_of_Life
2020-10-01 15:09:19 sm[m] likes lemmih's animation project too
2020-10-01 15:09:36 → xff0x joins (~fox@2001:1a81:5220:1600:f180:f194:ac6e:4ac8)
2020-10-01 15:10:42 <dminuoso> zzz... my Server.hs module where all servant code is being fed to takes up to a minute in the simplifer now..
2020-10-01 15:10:42 × knupfer quits (~Thunderbi@dynamic-046-114-145-216.46.114.pool.telefonica.de) (Read error: Connection reset by peer)
2020-10-01 15:10:48 <dminuoso> This is getting unbearable..
2020-10-01 15:10:52 <dminuoso> Dont even have any generics. :(
2020-10-01 15:11:45 <Cale> -fno-code should hurry it along ;)
2020-10-01 15:12:15 × borne quits (~fritjof@2001:638:708:30da:4ed8:5a31:2712:89a5) (Ping timeout: 272 seconds)
2020-10-01 15:12:27 → tzh joins (~tzh@c-73-94-222-143.hsd1.mn.comcast.net)
2020-10-01 15:13:35 <dminuoso> Im not sure whether that's particularly helpful for v2-test. ;)
2020-10-01 15:15:04 <AWizzArd> I would like to write a file to disk and know for sure that the file has been successfuly written. Is there a way to have a safe "flush to disk"? I need to know that the disk has flushed its caches and my data has certainly has been stored.
2020-10-01 15:15:34 → wroathe joins (~wroathe@c-68-54-25-135.hsd1.mn.comcast.net)
2020-10-01 15:15:52 <dminuoso> AWizzArd: Not trivially.
2020-10-01 15:15:59 <dminuoso> And not portably.
2020-10-01 15:16:21 <Cale> But on unix-likes, you want to call fsync
2020-10-01 15:16:24 <fendor> dminuoso, can't you use withFile?
2020-10-01 15:16:34 <dminuoso> Cale: that wont work
2020-10-01 15:16:39 <Cale> dminuoso: oh?
2020-10-01 15:16:43 <fendor> and call hFlush on the handle?
2020-10-01 15:16:55 <dminuoso> Cale: It depends on whether the harddisk itself has a write-back cache or not.
2020-10-01 15:17:08 <dminuoso> This is why databases should only run on disks with write-through caches.
2020-10-01 15:17:26 <dminuoso> fsync merely flushes os buffers onto the disks, but doesnt care or know what happens then
2020-10-01 15:17:30 <AWizzArd> Cale: I am on Linux.
2020-10-01 15:17:34 <Cale> Well, that's fair, though I wouldn't expect software to be able to do much more than that
2020-10-01 15:17:41 <dminuoso> Right
2020-10-01 15:17:55 <AWizzArd> dminuoso: I can buy the right harddisk if required.
2020-10-01 15:18:08 <dminuoso> AWizzArd: Make sure you buy one with write-through caches, and then fsync is enough.
2020-10-01 15:18:08 <AWizzArd> server disk for DBs, it’s fine
2020-10-01 15:18:14 <dminuoso> Note
2020-10-01 15:18:17 <AWizzArd> Okay, fsync is my friend.
2020-10-01 15:18:23 <dminuoso> That if you have a RAID controller that too must have write-through caching
2020-10-01 15:18:24 <Cale> http://hackage.haskell.org/package/cautious-file-1.0.2 looks like it has the basic idea.
2020-10-01 15:18:47 <dminuoso> AWizzArd: https://www.postgresql.org/docs/9.1/wal-reliability.html
2020-10-01 15:18:50 <dminuoso> This is a good guidance
2020-10-01 15:19:12 <dminuoso> Or well, better refer to the most recent version: https://www.postgresql.org/docs/13/wal-reliability.html
2020-10-01 15:20:04 <dminuoso> (Also take note about the hints of BBUs in raid controllers)
2020-10-01 15:20:41 <dminuoso> Furthermore, the notes regarding FLUSH CACHE EXT could be of interest to you.
2020-10-01 15:20:53 <dminuoso> In case you cant find a suitable write-through harddrive
2020-10-01 15:21:43 → Alucard joins (~Alucard@185.163.110.116)
2020-10-01 15:22:41 <Cale> Of course, another thing you can do is to use postgres to store all your stuff in the first place, so that at least the software tricks for reliability are handled. :)
2020-10-01 15:24:02 × kritzefitz quits (~kritzefit@fw-front.credativ.com) (Remote host closed the connection)
2020-10-01 15:24:14 × kindaro quits (6dbb76bb@h109-187-118-187.dyn.bashtel.ru) (Ping timeout: 245 seconds)
2020-10-01 15:24:15 × zebrag quits (~inkbottle@aaubervilliers-654-1-113-44.w86-198.abo.wanadoo.fr) (Quit: Konversation terminated!)
2020-10-01 15:24:37 → zebrag joins (~inkbottle@aaubervilliers-654-1-113-44.w86-198.abo.wanadoo.fr)
2020-10-01 15:26:01 × madjestic quits (~madjestic@86-88-72-244.fixed.kpn.net) (Ping timeout: 264 seconds)
2020-10-01 15:26:18 → toorevitimirp joins (~tooreviti@117.182.181.38)
2020-10-01 15:26:28 hackage kan-extensions 5.2.1 - Kan extensions, Kan lifts, the Yoneda lemma, and (co)density (co)monads https://hackage.haskell.org/package/kan-extensions-5.2.1 (ryanglscott)
2020-10-01 15:26:49 → heatsink joins (~heatsink@107-136-5-69.lightspeed.sntcca.sbcglobal.net)
2020-10-01 15:27:43 → mmohammadi9812 joins (~mmohammad@188.210.100.86)
2020-10-01 15:28:59 → conal joins (~conal@64.71.133.70)
2020-10-01 15:30:18 × toorevitimirp quits (~tooreviti@117.182.181.38) (Remote host closed the connection)
2020-10-01 15:31:36 → toorevitimirp joins (~tooreviti@117.182.181.38)
2020-10-01 15:32:46 → spew joins (uid195861@gateway/web/irccloud.com/x-nekawqgdgyhycrzn)
2020-10-01 15:33:19 → thir joins (~thir@p200300f27f0fc60004d129737887aa72.dip0.t-ipconnect.de)
2020-10-01 15:34:25 × snakemasterflex quits (~snakemast@213.100.206.23) (Ping timeout: 240 seconds)
2020-10-01 15:35:32 × avdb quits (~avdb@ip-62-235-13-127.dsl.scarlet.be) (Quit: WeeChat 2.9)
2020-10-01 15:35:35 × toorevitimirp quits (~tooreviti@117.182.181.38) (Remote host closed the connection)
2020-10-01 15:36:16 → toorevitimirp joins (~tooreviti@117.182.181.38)
2020-10-01 15:36:57 → Guest18 joins (567e8866@gateway/web/cgi-irc/kiwiirc.com/ip.86.126.136.102)
2020-10-01 15:37:05 → snakemasterflex joins (~snakemast@213.100.206.23)
2020-10-01 15:39:47 × thir quits (~thir@p200300f27f0fc60004d129737887aa72.dip0.t-ipconnect.de) (Ping timeout: 260 seconds)
2020-10-01 15:39:55 × zacts quits (~zacts@dragora/developer/zacts) (Quit: leaving)
2020-10-01 15:40:13 → zacts joins (~zacts@dragora/developer/zacts)
2020-10-01 15:42:07 × acidjnk_new quits (~acidjnk@p200300d0c72378548d78178f4051abec.dip0.t-ipconnect.de) (Ping timeout: 240 seconds)
2020-10-01 15:42:27 <dminuoso> Cale: Heh, I found an alternative to -fno-code, -O0 seems to work for v2-test just fine.
2020-10-01 15:42:28 hackage mattermost-api 50200.8.0 - Client API for Mattermost chat system https://hackage.haskell.org/package/mattermost-api-50200.8.0 (JonathanDaugherty)
2020-10-01 15:42:47 <dminuoso> It's amazing how the default -O setting takes over a minute for this. I dont even do type level tricks. :(
2020-10-01 15:43:20 <davean> dminuoso: Yah, -O0 is very fast. -fno-code is only slightly faster usually.
2020-10-01 15:43:28 hackage matterhorn 50200.10.2, mattermost-api-qc 50200.8.0 (JonathanDaugherty): https://qbin.io/dame-way-72tw
2020-10-01 15:44:31 monochrom sets mode -o monochrom
2020-10-01 15:45:53 × toorevitimirp quits (~tooreviti@117.182.181.38) (Remote host closed the connection)
2020-10-01 15:49:06 → chappi joins (~swaroop@157.49.85.251)
2020-10-01 15:49:29 × chappi quits (~swaroop@157.49.85.251) (Client Quit)
2020-10-01 15:50:48 × ericsagnes quits (~ericsagne@2405:6580:0:5100:6c67:5a40:c7fb:8ff8) (Ping timeout: 244 seconds)
2020-10-01 15:51:36 → avdb joins (~avdb@ip-62-235-13-127.dsl.scarlet.be)
2020-10-01 15:53:13 × merijn quits (~merijn@83-160-49-249.ip.xs4all.nl) (Ping timeout: 260 seconds)
2020-10-01 15:55:52 → justanotheruser joins (~justanoth@unaffiliated/justanotheruser)
2020-10-01 15:57:08 <AWizzArd> I once mentioned that I was using a package.yaml because there I need to list dependencies only once. Someone then explained that Cabal can now do the same. How can I do it?
2020-10-01 15:57:23 → chappi joins (~swaroop@157.49.85.251)
2020-10-01 15:57:27 <AWizzArd> I would like to list 25 dependencies and not repeat them again for a test or benchmark section.
2020-10-01 15:57:47 × wroathe quits (~wroathe@c-68-54-25-135.hsd1.mn.comcast.net) (Ping timeout: 240 seconds)
2020-10-01 15:59:02 × jespada quits (~jespada@90.254.241.6) (Ping timeout: 260 seconds)
2020-10-01 15:59:07 <monochrom> https://cabal.readthedocs.io/en/3.4/cabal-package.html#common-stanzas
2020-10-01 16:00:05 <AWizzArd> monochrom: Is this also available before Cabal 3.4 (which seems to not be released yet)?
2020-10-01 16:00:08 → jespada joins (~jespada@90.254.241.6)
2020-10-01 16:00:23 <monochrom> I think yes.
2020-10-01 16:00:30 × xcmw quits (~textual@dyn-72-33-0-89.uwnet.wisc.edu) (Quit: My MacBook has gone to sleep. ZZZzzz…)
2020-10-01 16:00:38 <AWizzArd> monochrom: but yeah, those `common` things were exactly what I was looking for, thx!
2020-10-01 16:00:44 → Rudd0 joins (~Rudd0@185.189.115.108)
2020-10-01 16:00:47 <monochrom> Don't forget that you also need https://cabal.readthedocs.io/en/3.4/cabal-package.html#pkg-field-cabal-version to enable, heh, what I would call "cabal extensions"
2020-10-01 16:00:56 × chappi quits (~swaroop@157.49.85.251) (Client Quit)
2020-10-01 16:01:19 → tanuki joins (~quassel@173.168.154.189)
2020-10-01 16:01:58 hackage rebase 1.9.1 - A more progressive alternative to the "base" package https://hackage.haskell.org/package/rebase-1.9.1 (NikitaVolkov)
2020-10-01 16:02:04 <monochrom> I refer to the version-3.4 manual because it is well structured.
2020-10-01 16:02:05 → chappi joins (~swaroop@157.49.85.251)
2020-10-01 16:02:55 <AWizzArd> monochrom: I am not really sure what this means, what I need to enable. Should I mention `cabal-version: 3.2` explicitly in my .cabal file? Or should `cabal-version:` no longer be used?
2020-10-01 16:03:13 → ericsagnes joins (~ericsagne@2405:6580:0:5100:4135:276:e32f:4d13)
2020-10-01 16:03:28 hackage rebase 1.10 - A more progressive alternative to the "base" package https://hackage.haskell.org/package/rebase-1.10 (NikitaVolkov)
←Prev  Next→
Page 1 .. 349 350 351 352 353 354 355 356 357 358 359 .. 5022

All times are in UTC.