Home liberachat/#haskell: Logs Calendar

Logs: liberachat/#haskell

←Prev  Next→ 1,804,106 events total
2021-08-18 17:49:19 <monochrom> And even if it's in a hotspot and the more humane code is under-optimized, the GHC people will love to know your use case, then go think about how to optimize it. There is still a possible future in which the humane version is optimized.
2021-08-18 17:51:10 <dminuoso> I mean granted, there's certain behaviors that generally lead to more performant code.
2021-08-18 17:52:13 <dminuoso> But that's something you generally develop with experience, and are often still wrong.
2021-08-18 17:52:37 <monochrom> Drew[m]1, it did come out as seperate lines, no worries, your IRC client split it for you :)
2021-08-18 17:52:49 <dminuoso> `String`, despite having a horribly inefficient cache-hostile representation, seems to perform generally good enough to not be a hot spot in any of my programs..
2021-08-18 17:52:57 Tuplanolla joins (~Tuplanoll@91-159-69-50.elisa-laajakaista.fi)
2021-08-18 17:53:11 <dminuoso> At least not a measurable/relevant hotspot
2021-08-18 17:53:54 <davean> tring HIGHLY depends on wher in the code it is, also when it is a problem its generally a very spread out problem
2021-08-18 17:53:59 <monochrom> Idiomatic Haskell tends not to do heavy string processing in the first place anyway. This is not Perl or Tcl or shell script.
2021-08-18 17:54:04 <davean> But it can be the best option in some cases
2021-08-18 17:57:29 <monochrom> HTML scrappers would need optimized strings. But HTML scrappers are no longer hip this year. (Yes, 5 or 10 years ago it was hip, every other day someone would come here saying "I'm writing an HTML scrapper, this is taking 1GB for a 100MB file...")
2021-08-18 17:59:03 wallymathieu joins (~wallymath@81-234-151-21-no94.tbcn.telia.com)
2021-08-18 18:01:23 × hnOsmium0001 quits (uid453710@id-453710.stonehaven.irccloud.com) (Quit: Connection closed for inactivity)
2021-08-18 18:02:04 <maerwald> ppl are doing that with haskell
2021-08-18 18:02:06 <maerwald> see xeno
2021-08-18 18:02:48 <maerwald> Here's a maintained fork https://gitlab.com/migamake/xeno
2021-08-18 18:03:22 <maerwald> oddly, it's faster than some C parsers
2021-08-18 18:03:34 <maerwald> but it's not idiomatic haskell in any sense
2021-08-18 18:03:49 <maerwald> just bytestring trickery optimizing to pointer tricks
2021-08-18 18:04:45 Erutuon joins (~Erutuon@user/erutuon)
2021-08-18 18:04:48 × polyphem quits (~polyphem@2a02:810d:640:776c:f4c0:a27a:540e:c15e) (Read error: Connection reset by peer)
2021-08-18 18:05:13 <davean> maerwald: I don't know what Haskell you're reading, pointer tricks on bytestrings is what most of the Haskell I've read lately is all about! :)
2021-08-18 18:05:42 <maerwald> I'll be impressed if we have a fast streamly based XML parser
2021-08-18 18:05:44 <maerwald> not before
2021-08-18 18:06:11 hnOsmium0001 joins (uid453710@id-453710.stonehaven.irccloud.com)
2021-08-18 18:06:37 <monochrom> Well yeah, ever since bytestring, HTML scrapper performance became a solved problem.
2021-08-18 18:07:22 × gehmehgeh quits (~user@user/gehmehgeh) (Quit: Leaving)
2021-08-18 18:08:54 gehmehgeh joins (~user@user/gehmehgeh)
2021-08-18 18:10:59 keutoi joins (~keutoi@223.238.95.231)
2021-08-18 18:16:39 aegon joins (~mike@174.127.249.180)
2021-08-18 18:22:18 <dminuoso> code optimizing to memory tricks is a fairly legit and common thing to do to make code fast..
2021-08-18 18:22:25 <dminuoso> just saying..
2021-08-18 18:27:03 × fef quits (~thedawn@user/thedawn) (Remote host closed the connection)
2021-08-18 18:27:22 <monochrom> :)
2021-08-18 18:27:55 <aegon> huh, how do you go about testing somethign that requires a postgresql connection trying to reason about testing functions that interact with postgresql simple, should i create a dummy db and test against that :?
2021-08-18 18:28:19 <dminuoso> aegon: That's probably the most common way, yes.
2021-08-18 18:28:58 <dminuoso> Depending on what you want to test, possibly mocking or some tagless final encoding could also help. Also, if you can write code that is portable with sqlite as well, you can use sqlite for testing.
2021-08-18 18:29:41 <dminuoso> Or you can use unit tests if you can decouple the logic from the database
2021-08-18 18:29:51 <dminuoso> And bypass the need for a database entirely
2021-08-18 18:30:06 <maerwald> dminuoso: I dunno, in haskell it feels particularly fragile (and often is), because how things optimize/inline may change drastically from GHC to GHC and library version
2021-08-18 18:31:29 × keutoi quits (~keutoi@223.238.95.231) (Ping timeout: 248 seconds)
2021-08-18 18:33:07 keutoi joins (~keutoi@157.47.26.152)
2021-08-18 18:34:25 × raehik quits (~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) (Ping timeout: 268 seconds)
2021-08-18 18:36:24 × dyeplexer quits (~dyeplexer@user/dyeplexer) (Remote host closed the connection)
2021-08-18 18:48:24 × keutoi quits (~keutoi@157.47.26.152) (Quit: leaving)
2021-08-18 18:48:25 × t0zy quits (~t0zy@49.207.220.61) (Remote host closed the connection)
2021-08-18 18:48:40 t0zy joins (~t0zy@49.207.220.61)
2021-08-18 18:51:15 <dsal> aegon: I've done something like this by modeling my effects separately in a class and then having different effect providers. This also helped me when I suspected I had a performance issue in my DB layer which ended up being unaffected by a memory-only provider.
2021-08-18 18:54:32 <gambpang> In case ppl care, the context is that we prefer `f . g . h $ x` (or `(f . g . h) x`) at work exactly because of that "obvious factorization" and nobody knew what if any costs there were over using chaining ($)
2021-08-18 18:55:28 <Cale> gambpang: The compiled code will typically be identical
2021-08-18 18:56:18 d0ku joins (~d0ku@178.43.198.70.ipv4.supernova.orange.pl)
2021-08-18 18:58:43 burnsidesLlama joins (~burnsides@dhcp168-023.wadham.ox.ac.uk)
2021-08-18 18:59:10 × d0ku quits (~d0ku@178.43.198.70.ipv4.supernova.orange.pl) (Client Quit)
2021-08-18 18:59:21 d0ku joins (~d0ku@178.43.198.70.ipv4.supernova.orange.pl)
2021-08-18 19:04:26 × wallymathieu quits (~wallymath@81-234-151-21-no94.tbcn.telia.com) (Quit: My MacBook has gone to sleep. ZZZzzz…)
2021-08-18 19:04:42 tput joins (~tim@S0106a84e3fe54613.ed.shawcable.net)
2021-08-18 19:08:24 shapr joins (~user@pool-100-36-247-68.washdc.fios.verizon.net)
2021-08-18 19:14:51 × burnsidesLlama quits (~burnsides@dhcp168-023.wadham.ox.ac.uk) (Remote host closed the connection)
2021-08-18 19:14:56 merijn joins (~merijn@83-160-49-249.ip.xs4all.nl)
2021-08-18 19:17:46 × gehmehgeh quits (~user@user/gehmehgeh) (Remote host closed the connection)
2021-08-18 19:18:28 gehmehgeh joins (~user@user/gehmehgeh)
2021-08-18 19:18:41 × Cajun quits (~Cajun@user/cajun) (Quit: Client closed)
2021-08-18 19:18:54 burnsidesLlama joins (~burnsides@dhcp168-023.wadham.ox.ac.uk)
2021-08-18 19:21:24 Cajun joins (~Cajun@user/cajun)
2021-08-18 19:22:44 × mc47 quits (~mc47@xmonad/TheMC47) (Remote host closed the connection)
2021-08-18 19:40:10 × Lord_of_Life quits (~Lord@user/lord-of-life/x-2819915) (Ping timeout: 252 seconds)
2021-08-18 19:42:06 Lord_of_Life joins (~Lord@user/lord-of-life/x-2819915)
2021-08-18 19:42:18 × ystael quits (~ystael@user/ystael) (Read error: Connection reset by peer)
2021-08-18 19:43:50 gethuen joins (uid502979@id-502979.stonehaven.irccloud.com)
2021-08-18 19:45:25 burnside_ joins (~burnsides@dhcp168-023.wadham.ox.ac.uk)
2021-08-18 19:45:26 × burnsidesLlama quits (~burnsides@dhcp168-023.wadham.ox.ac.uk) (Read error: Connection reset by peer)
2021-08-18 19:46:09 × alx741 quits (~alx741@181.196.68.125) (Ping timeout: 248 seconds)
2021-08-18 19:48:58 × merijn quits (~merijn@83-160-49-249.ip.xs4all.nl) (Ping timeout: 252 seconds)
2021-08-18 19:49:08 <aegon> dsal: dminuoso: roger that I'll try each and see how things vary maybe i should have used persistant vs postgresql-simple
2021-08-18 19:52:40 × fabfianda quits (~fabfianda@37.183.255.57) (Ping timeout: 240 seconds)
2021-08-18 19:57:55 × _ht quits (~quassel@82-169-194-8.biz.kpn.net) (Remote host closed the connection)
2021-08-18 19:59:39 alx741 joins (~alx741@181.196.69.234)
2021-08-18 20:01:58 jgeerds joins (~jgeerds@55d45555.access.ecotel.net)
2021-08-18 20:03:37 raehik joins (~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net)
2021-08-18 20:05:40 × juhp quits (~juhp@128.106.188.220) (Ping timeout: 268 seconds)
2021-08-18 20:11:47 × hendursaga quits (~weechat@user/hendursaga) (Remote host closed the connection)
2021-08-18 20:12:23 hendursaga joins (~weechat@user/hendursaga)
2021-08-18 20:12:34 chisui joins (~chisui@200116b8681e48004d4a4305e410a0e6.dip.versatel-1u1.de)
2021-08-18 20:13:39 × burnside_ quits (~burnsides@dhcp168-023.wadham.ox.ac.uk) (Remote host closed the connection)
2021-08-18 20:13:44 <chisui> Hey, does anyone have a clue why the sound is skipping in this application? https://github.com/chisui/fsynth/blob/master/src/Main.hs I fear that the reason is that it's the context switch from the generating thread to the writing one.
2021-08-18 20:14:08 burnsidesLlama joins (~burnsides@dhcp168-023.wadham.ox.ac.uk)
2021-08-18 20:16:11 × burnsidesLlama quits (~burnsides@dhcp168-023.wadham.ox.ac.uk) (Read error: Connection reset by peer)
2021-08-18 20:16:22 burnsidesLlama joins (~burnsides@dhcp168-023.wadham.ox.ac.uk)
2021-08-18 20:16:32 × burnsidesLlama quits (~burnsides@dhcp168-023.wadham.ox.ac.uk) (Remote host closed the connection)
2021-08-18 20:16:50 merijn joins (~merijn@83-160-49-249.ip.xs4all.nl)
2021-08-18 20:17:04 burnsidesLlama joins (~burnsides@dhcp168-023.wadham.ox.ac.uk)
2021-08-18 20:17:24 × gehmehgeh quits (~user@user/gehmehgeh) (Remote host closed the connection)
2021-08-18 20:18:08 gehmehgeh joins (~user@user/gehmehgeh)
2021-08-18 20:18:41 <shapr> chisui: does it help any to spawn off play as a separate thread?
2021-08-18 20:19:12 <shapr> you have -threaded, so I'd guess garbage collection is already on a separate thread?
2021-08-18 20:19:25 <dsal> I'm suspicious of `threadDelay 50`
2021-08-18 20:19:53 <davean> shapr: uh? Is it using hte pauseless GC?
2021-08-18 20:19:59 <davean> Otherwise thats not how threads and GC work
2021-08-18 20:20:14 <chisui> shapr: spawning a new thread doesn't help :(
2021-08-18 20:20:54 <chisui> dsal: the delay is just so that the buffer doesn't overflow. I checked and the buffer is always full enough when popped.

All times are in UTC.