2024/11/04

Newest at the top

2024-11-04 22:03:41 +0100merijn(~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 265 seconds)
2024-11-04 22:01:16 +0100morb(~morb@pool-108-41-100-120.nycmny.fios.verizon.net) (Ping timeout: 265 seconds)
2024-11-04 21:59:05 +0100LainExperiments6(~LainExper@user/LainExperiments) (Ping timeout: 256 seconds)
2024-11-04 21:58:43 +0100merijn(~merijn@128-137-045-062.dynamic.caiway.nl) merijn
2024-11-04 21:56:49 +0100morb(~morb@pool-108-41-100-120.nycmny.fios.verizon.net)
2024-11-04 21:55:07 +0100CoolMa7(~CoolMa7@95.91.137.87) CoolMa7
2024-11-04 21:53:59 +0100LainExperiments(~LainExper@user/LainExperiments) (Ping timeout: 256 seconds)
2024-11-04 21:50:31 +0100LainExperiments6(~LainExper@user/LainExperiments) LainExperiments
2024-11-04 21:48:14 +0100 <monochrom> I use a much simpler hello world. It just counts how many times it has been visited. And the count isn't even saved permanently.
2024-11-04 21:47:00 +0100merijn(~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 246 seconds)
2024-11-04 21:45:29 +0100 <Inst> monochrom: I'm just making 100 different hello worlds. Getting servant to expose a directory is a hello-world
2024-11-04 21:45:15 +0100 <Inst> thanks for the help, i guess
2024-11-04 21:42:58 +0100wootehfoot(~wootehfoo@user/wootehfoot) (Read error: Connection reset by peer)
2024-11-04 21:42:41 +0100remedan(~remedan@ip-62-245-108-153.bb.vodafone.cz) remedan
2024-11-04 21:42:15 +0100 <Clint> warp's pretty simple for just serving a directory
2024-11-04 21:41:50 +0100 <tomsmeding> Inst: the playground uses snap-server; relatively bare-bones, but works and is not extremely heavy-weight
2024-11-04 21:41:35 +0100 <geekosaur> the thing about servant is that it heavily uses type level programming. on the one hand that means it's pretty thoroughly debugged at compile time. on the other it makes it harder to use, so for very simple jobs you may want something easier to wrangle
2024-11-04 21:40:54 +0100remedan(~remedan@ip-62-245-108-153.bb.vodafone.cz) (Quit: Bye!)
2024-11-04 21:40:38 +0100 <monochrom> To expose a directory, just use apache. >:)
2024-11-04 21:40:25 +0100merijn(~merijn@128-137-045-062.dynamic.caiway.nl) merijn
2024-11-04 21:40:18 +0100 <Inst> and i'm annoyed because i'm using Data.List.intersperse and Data.Foldable.fold
2024-11-04 21:40:00 +0100 <Inst> or maybe I just don't understand captureall, I'm trying to rig servant to just expose a directory
2024-11-04 21:39:41 +0100 <Inst> any you could recommend?
2024-11-04 21:39:05 +0100 <tomsmeding> there are various alternatives with various feature sets and library designs
2024-11-04 21:38:46 +0100 <Inst> i mean you could just say there is no alternative
2024-11-04 21:38:30 +0100 <tomsmeding> is that new enough?
2024-11-04 21:38:28 +0100 <tomsmeding> Inst: last upload to hackage August 30th, this year
2024-11-04 21:37:19 +0100 <Inst> afaik, like, scotty and spock were standard for a long time, then hecate recommends twain, which as far as i understand is standard for "simple" webservers
2024-11-04 21:36:32 +0100 <Inst> last blog entry 2018
2024-11-04 21:36:30 +0100 <Inst> https://www.servant.dev
2024-11-04 21:36:04 +0100ash3en(~Thunderbi@2a03:7846:b6eb:101:93ac:a90a:da67:f207) (Quit: ash3en)
2024-11-04 21:36:00 +0100 <geekosaur> it wasn't updated 5 minutes ago?
2024-11-04 21:35:47 +0100 <geekosaur> why do you think it's obsolete?
2024-11-04 21:35:28 +0100 <Inst> 2 minutes, good enough, do people still use servant, or is it sort of obsolete in web framework land?
2024-11-04 21:35:07 +0100 <Inst> ...
2024-11-04 21:33:21 +0100 <int-e> It's much easier to ensure the absence of such allocations by using C.
2024-11-04 21:33:18 +0100 <tomsmeding> (strstr() is typically a thing that you do want to do with SIMD instructions)
2024-11-04 21:32:52 +0100 <tomsmeding> ( https://github.com/ndmitchell/hoogle/blob/master/cbits/text_search.c )
2024-11-04 21:32:52 +0100 <int-e> bytestring/vector jump through a lot of hoops to hopefully avoid allocations in inner loops
2024-11-04 21:32:48 +0100 <tomsmeding> (assuming that the strstr() call is replaced with some other FFI call; perhaps eliminating the overhead of many FFI calls for the strstr()s already justifies putting the whole loop in C)
2024-11-04 21:32:12 +0100 <tomsmeding> (but as I said, this code doesn't look like the kind of code that would really benefit from that)
2024-11-04 21:31:39 +0100 <tomsmeding> that is good for 2x-4x improvement in some cases
2024-11-04 21:31:28 +0100 <tomsmeding> hellwolf: GHC will not generate SIMD instructions, and a C compiler will, if your code is amenable to it
2024-11-04 21:30:45 +0100 <int-e> It has little to do with where malloc-ed memory resides. The fact that it's pinned makes it safe to use in safe foreign calls.
2024-11-04 21:30:39 +0100 <haskellbridge> Any short example of it?
2024-11-04 21:30:39 +0100 <haskellbridge> <hellwolf> > Haskell, or rather GHC, isn't great at compiling tight inner loops.
2024-11-04 21:30:23 +0100 <tomsmeding> the C code doesn't look particularly vectorisable, though
2024-11-04 21:30:14 +0100 <int-e> geekosaur: That depends on whether you make an unsafe or a safe foreign call.
2024-11-04 21:29:31 +0100 <int-e> Haskell, or rather GHC, isn't great at compiling tight inner loops.
2024-11-04 21:29:26 +0100 <geekosaur> (IIRC malloc gives you pinned memory, which therefore doesn't live in the heap, which therefore means it comes from C's malloc, which means your thread is blocked in FFI and if another thread causes a GC the RTS will block trying to synchronize with your thread while it's in the FFI call)