2025/01/08

Newest at the top

2025-01-08 11:42:28 +0100 <haskellbridge> <magic_rb> But that would then mean id have to write different preambles per architecture which i dont really feel like doing :)
2025-01-08 11:42:06 +0100 <haskellbridge> <magic_rb> Im kind of tempted to implement the sparse sets as foreign primops in C
2025-01-08 11:39:47 +0100 <merijn> it's a slightly higher wrapper around stuff like ghc-prim
2025-01-08 11:39:34 +0100 <merijn> primitive is fine too
2025-01-08 11:39:26 +0100 <merijn> Just not very portable, but that only matters in a universe where we still pretend anything but GHC matters :P
2025-01-08 11:39:24 +0100 <haskellbridge> <magic_rb> should i not be using primitive?
2025-01-08 11:39:03 +0100 <merijn> That said, (most of) ghc-prim is perfectly safe and really not that complicated
2025-01-08 11:39:00 +0100 <haskellbridge> <magic_rb> yeah fair, loking at the primitive package and PrimArray, i think thats what i need
2025-01-08 11:38:36 +0100 <merijn> magic_rb: Once you start wondering "how do I avoid boxing/reboxing" you can't really avoid looking at that kinda stuff ;)
2025-01-08 11:37:54 +0100 <tomsmeding> I see
2025-01-08 11:37:37 +0100tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…)
2025-01-08 11:37:32 +0100 <haskellbridge> <magic_rb> yeah i didnt want to go that deep, was hoping i could avoid it :)
2025-01-08 11:37:03 +0100 <merijn> magic_rb: You should probably take some time browsing ghc-prim if you haven't yet :)
2025-01-08 11:35:45 +0100mari-estel(~mari-este@user/mari-estel) (Ping timeout: 260 seconds)
2025-01-08 11:34:42 +0100 <haskellbridge> <magic_rb> Which is a lot if exists is called hundreds of times per frame
2025-01-08 11:34:30 +0100 <haskellbridge> <magic_rb> tomsmeding i looked at the core and its doing boxing unboxing in a single call to exists, i counted 3 or 4 boxes unboxes
2025-01-08 11:33:38 +0100mari50420(~mari-este@user/mari-estel) mari-estel
2025-01-08 11:33:27 +0100__monty__(~toonn@user/toonn) toonn
2025-01-08 11:29:55 +0100jespada(~jespada@2800:a4:f9:a300:c8c1:20a5:1a94:f1) (Quit: My Mac has gone to sleep. ZZZzzz…)
2025-01-08 11:28:58 +0100Guest17(~Guest17@91.243.81.204) (Quit: Client closed)
2025-01-08 11:26:03 +0100 <tomsmeding> https://hackage.haskell.org/package/vector-0.13.2.0/src/internal/unbox-tuple-instances
2025-01-08 11:23:14 +0100 <tomsmeding> if you want to read manually from a MutableByteArray, https://hackage.haskell.org/package/base-4.19.0.0/docs/GHC-Exts.html#v:readInt64Array-35-
2025-01-08 11:22:38 +0100 <tomsmeding> are you sure you're not looking for Data.Vector.Storable.Mutable?
2025-01-08 11:21:43 +0100 <tomsmeding> one containing the fst components, the other containing the snd components
2025-01-08 11:21:28 +0100 <tomsmeding> an `MVector s (Int, Int)` in the end consists of _two_ `MutableByteArray s`es
2025-01-08 11:20:29 +0100 <tomsmeding> and also, the 'a' here is a boxed type
2025-01-08 11:20:10 +0100 <tomsmeding> but unboxed types in an unboxed vector (as opposed to a _storable_ vector) are stored in struct-of-arrays format
2025-01-08 11:19:31 +0100 <tomsmeding> recall my earlier comments on the ghc unboxer
2025-01-08 11:19:20 +0100 <tomsmeding> are you sure you need that for performance?
2025-01-08 11:17:34 +0100Guest17(~Guest17@91.243.81.204)
2025-01-08 11:17:22 +0100Guest17(~Guest17@91.243.81.204) (Quit: Client closed)
2025-01-08 11:15:55 +0100tnt2tnt1
2025-01-08 11:13:37 +0100tnt2(~Thunderbi@user/tnt1) tnt1
2025-01-08 11:13:34 +0100tnt1(~Thunderbi@user/tnt1) (Ping timeout: 272 seconds)
2025-01-08 11:07:16 +0100 <haskellbridge> <magic_rb> is there no way to directly read from a Unboxed Mutable Vector using Int# as the index and read the undoxed type directly? https://hackage.haskell.org/package/vector-0.13.2.0/docs/Data-Vector-Unboxed-Mutable.html i dont see anything in the module
2025-01-08 11:06:06 +0100tomsmeding(~tomsmedin@2a01:4f8:c0c:5e5e::2) tomsmeding
2025-01-08 11:04:23 +0100tomsmeding(~tomsmedin@2a01:4f8:c0c:5e5e::2) (Quit: ZNC 1.9.1 - https://znc.in)
2025-01-08 11:01:01 +0100merijn(~merijn@77.242.116.146) merijn
2025-01-08 10:58:36 +0100xff0x(~xff0x@fsb6a9491c.tkyc517.ap.nuro.jp) (Ping timeout: 246 seconds)
2025-01-08 10:57:56 +0100merijn(~merijn@77.242.116.146) (Ping timeout: 252 seconds)
2025-01-08 10:55:43 +0100forell(~forell@user/forell) forell
2025-01-08 10:55:22 +0100CiaoSen(~Jura@2a05:5800:213:8800:ca4b:d6ff:fec1:99da) CiaoSen
2025-01-08 10:51:14 +0100merijn(~merijn@77.242.116.146) merijn
2025-01-08 10:46:58 +0100ash3en(~Thunderbi@2a03:7846:b6eb:101:93ac:a90a:da67:f207) (Ping timeout: 265 seconds)
2025-01-08 10:46:01 +0100Guest17(~Guest17@91.243.81.204)
2025-01-08 10:45:12 +0100mud(~mud@user/kadoban) kadoban
2025-01-08 10:44:47 +0100mud(~mud@user/kadoban) (Remote host closed the connection)
2025-01-08 10:44:41 +0100p3n(~p3n@217.198.124.246) p3n
2025-01-08 10:44:08 +0100p3n(~p3n@2a00:19a0:3:7c:0:d9c6:7cf6:1) (Quit: ZNC 1.8.2 - https://znc.in)
2025-01-08 10:43:31 +0100 <ncf> monochrom: what relation do you use for b? i'd think a function Bool → b is enough