Logs: freenode/#haskell
| 2021-04-17 01:56:06 | × | gzj quits (~gzj@unaffiliated/gzj) (Remote host closed the connection) |
| 2021-04-17 01:56:27 | → | gzj joins (~gzj@unaffiliated/gzj) |
| 2021-04-17 01:57:38 | → | zq joins (~zq@xorshift.org) |
| 2021-04-17 01:57:42 | → | kiweun joins (~kiweun@2607:fea8:2a62:9600:5118:3d31:e060:1aa9) |
| 2021-04-17 01:57:54 | <zq> | where is `instance Ord String` defined? |
| 2021-04-17 01:58:31 | <zq> | and in general, how to locate instance definition for some type? |
| 2021-04-17 01:58:52 | <glguy> | It's not, but there's an instance for [a] |
| 2021-04-17 01:59:07 | × | gzj quits (~gzj@unaffiliated/gzj) (Remote host closed the connection) |
| 2021-04-17 01:59:18 | <glguy> | Ghci's :info command helps |
| 2021-04-17 01:59:27 | → | gzj joins (~gzj@unaffiliated/gzj) |
| 2021-04-17 01:59:43 | <zq> | actually, disregard |
| 2021-04-17 01:59:47 | <zq> | glguy: right, thanks |
| 2021-04-17 01:59:54 | <zq> | unfortunately https://hackage.haskell.org/package/base-4.15.0.0/ghc-prim-0.7.0/src/GHC-Classes.html#compare 404s |
| 2021-04-17 02:00:06 | × | gzj quits (~gzj@unaffiliated/gzj) (Read error: Connection reset by peer) |
| 2021-04-17 02:00:26 | → | gzj joins (~gzj@unaffiliated/gzj) |
| 2021-04-17 02:00:38 | <zq> | disregard, found it |
| 2021-04-17 02:00:39 | <glguy> | Why are you looking at that one? |
| 2021-04-17 02:00:53 | × | cyphase quits (~cyphase@unaffiliated/cyphase) (Ping timeout: 240 seconds) |
| 2021-04-17 02:01:51 | <zq> | glguy: looking at that hackage link or Ord [Char] in general? |
| 2021-04-17 02:02:00 | <glguy> | That link |
| 2021-04-17 02:02:23 | <zq> | i figured the hackage page for Ord might have some clues |
| 2021-04-17 02:02:27 | <c_wraith> | I mean, I'm pretty curious why you're looking at Ord [a] in general, too |
| 2021-04-17 02:03:23 | <zq> | c_wraith: because i wanted to know if `compare [] (_:_) == LT` in general, ie could there be an Ord a for which GT makes more sense instead |
| 2021-04-17 02:03:44 | <c_wraith> | Doesn't the instance head tell you that? |
| 2021-04-17 02:04:20 | <zq> | i mean i got my answer from the instance definition |
| 2021-04-17 02:04:28 | <zq> | https://github.com/ghc/ghc/blob/master/libraries/ghc-prim/GHC/Classes.hs#L393 |
| 2021-04-17 02:04:31 | <c_wraith> | But you didn't even need to. the docs tell you explicitly |
| 2021-04-17 02:04:32 | → | rdivyanshu joins (uid322626@gateway/web/irccloud.com/x-jlksuktjqlwcmaao) |
| 2021-04-17 02:04:52 | <c_wraith> | "instance Ord a => Ord [a]" is enough to tell you that |
| 2021-04-17 02:05:21 | <zq> | ...i am slow and still don't follow |
| 2021-04-17 02:06:07 | <zq> | i'm not seeing what within the hackage docs for Ord would indicate this |
| 2021-04-17 02:06:25 | <c_wraith> | The instance head is sufficient. |
| 2021-04-17 02:06:45 | <c_wraith> | You know that the only way the element type can be used is via the Ord instance. |
| 2021-04-17 02:06:59 | <c_wraith> | Which is far from enough to distinguish types that it's comparing |
| 2021-04-17 02:07:20 | <c_wraith> | So the equality algorithm must not use that information |
| 2021-04-17 02:08:44 | <zq> | what's to stop someone from defining `instance Ord a => Ord (Evil [a]) where { compare (Evil []) (Evil (_:_)) = GT; ... }` just for fun? |
| 2021-04-17 02:09:02 | <c_wraith> | Nothing, but that's not an instance defined for [] |
| 2021-04-17 02:09:06 | <zq> | that deoesn't really violate the Ord laws |
| 2021-04-17 02:09:18 | → | cyphase joins (~cyphase@unaffiliated/cyphase) |
| 2021-04-17 02:10:04 | <c_wraith> | in Haskell, types are *incredibly* powerful documentation. type variables in particular, tell you a lot about what implementation can't be doing. |
| 2021-04-17 02:10:12 | <zq> | i was using Evil as a newtype to illustrate that the actual definition for compare :: Ord a => [a] -> [a] -> Ordering could have just as well be defined differently |
| 2021-04-17 02:10:33 | <c_wraith> | It could be defined differently than it is *for all element types* |
| 2021-04-17 02:10:44 | <c_wraith> | It can't be defined differently than it is for *some element type* |
| 2021-04-17 02:10:44 | <zq> | what's your point? |
| 2021-04-17 02:11:16 | <c_wraith> | My point is that the type already told you that checking at any one type told you its behavior for all types |
| 2021-04-17 02:11:26 | <zq> | > compare "a" "abcd" -- do you mean to say that this result alone is enough to know the definition of Ord [a]? |
| 2021-04-17 02:11:28 | <lambdabot> | LT |
| 2021-04-17 02:11:51 | <c_wraith> | No, I also need to see instance Ord a => Ord [a] |
| 2021-04-17 02:12:00 | <c_wraith> | those two pieces of information are sufficient |
| 2021-04-17 02:12:15 | <zq> | sure, but that misses the point of my original question |
| 2021-04-17 02:12:27 | <zq> | "ie could there be an Ord a for which GT makes more sense instead" |
| 2021-04-17 02:12:49 | <zq> | what if i didn't want a lexicographic sort |
| 2021-04-17 02:12:57 | <c_wraith> | then you need to use a different type |
| 2021-04-17 02:13:16 | <c_wraith> | a different type can do different things |
| 2021-04-17 02:13:43 | <zq> | actually, the saner thing to do would be to not even use `compare` for that |
| 2021-04-17 02:15:53 | <zq> | in any case, the definition for Ord [a] seems arbitrary |
| 2021-04-17 02:18:43 | <c_wraith> | in some sense, yes. in another sense, it's the only definition that gives strings the expected ordering. Of course, that's just more evidence type String = [Char] is bad |
| 2021-04-17 02:19:10 | <wz1000> | Has anyone noticed that System.IO.MMap.mmapFileByteStringLazy is horribly broken? |
| 2021-04-17 02:19:32 | <wz1000> | try reading a file greater than 500k and printing it out |
| 2021-04-17 02:19:36 | <c_wraith> | I don't think anything with that name can be not broken |
| 2021-04-17 02:19:51 | <c_wraith> | memory-mapped IO is a bad fit for immutability |
| 2021-04-17 02:20:35 | <wz1000> | ByteStrings are just mutable buffers we pretend are immutable |
| 2021-04-17 02:20:53 | <c_wraith> | No, we don't just pretend. we tell GHC |
| 2021-04-17 02:21:09 | <c_wraith> | and when you lie to GHC, it's your fault when things break |
| 2021-04-17 02:21:20 | <wz1000> | anyway, can someone test this out on their machine? |
| 2021-04-17 02:22:05 | × | gzj quits (~gzj@unaffiliated/gzj) (Remote host closed the connection) |
| 2021-04-17 02:22:25 | → | gzj joins (~gzj@unaffiliated/gzj) |
| 2021-04-17 02:22:34 | <wz1000> | I'm pretty sure the problem is not in the bytestring interface |
| 2021-04-17 02:23:01 | <wz1000> | its that the pointers returned by mmapFileForeignPtrLazyChunk are bogus |
| 2021-04-17 02:24:21 | <wz1000> | the first chunk seems to be fine, the rest are random pointers into memory |
| 2021-04-17 02:28:19 | × | Tario quits (~Tario@201.192.165.173) (Read error: Connection reset by peer) |
| 2021-04-17 02:30:33 | <c_wraith> | that use of castIntToPtr looks like undefined behavior |
| 2021-04-17 02:32:23 | <c_wraith> | yeah, it's passing it to C code. Casting back the other direction in the C code is definitely UB |
| 2021-04-17 02:32:38 | → | Tario joins (~Tario@201.192.165.173) |
| 2021-04-17 02:37:00 | → | star_cloud joins (~star_clou@ec2-34-220-44-120.us-west-2.compute.amazonaws.com) |
| 2021-04-17 02:43:55 | × | theDon quits (~td@94.134.91.133) (Ping timeout: 252 seconds) |
| 2021-04-17 02:45:29 | → | theDon joins (~td@muedsl-82-207-238-217.citykom.de) |
| 2021-04-17 02:48:18 | → | FinnElija joins (~finn_elij@gateway/tor-sasl/finnelija/x-67402716) |
| 2021-04-17 02:48:18 | finn_elija | is now known as Guest98695 |
| 2021-04-17 02:48:18 | FinnElija | is now known as finn_elija |
| 2021-04-17 02:50:56 | × | Sheilong quits (uid293653@gateway/web/irccloud.com/x-hrpqjuatvrzojcmn) () |
| 2021-04-17 02:51:33 | × | Guest98695 quits (~finn_elij@gateway/tor-sasl/finnelija/x-67402716) (Ping timeout: 240 seconds) |
| 2021-04-17 02:52:27 | → | drbean_ joins (~drbean@TC210-63-209-50.static.apol.com.tw) |
| 2021-04-17 02:54:31 | × | cyphase quits (~cyphase@unaffiliated/cyphase) (Ping timeout: 268 seconds) |
| 2021-04-17 02:57:14 | → | cyphase joins (~cyphase@unaffiliated/cyphase) |
| 2021-04-17 03:00:02 | × | haasn quits (~nand@mpv/developer/haasn) (Quit: ZNC 1.7.5+deb4 - https://znc.in) |
| 2021-04-17 03:01:20 | → | haasn joins (~nand@mpv/developer/haasn) |
| 2021-04-17 03:02:53 | × | lambdaman quits (~lambdaman@s66-183-152-156.bc.hsia.telus.net) (Ping timeout: 240 seconds) |
| 2021-04-17 03:04:20 | → | wickedjargon joins (~ff@2607:9880:2198:4e:aad4:1e17:671e:79b1) |
| 2021-04-17 03:06:28 | × | elliott_ quits (~elliott_@pool-108-18-30-46.washdc.fios.verizon.net) (Ping timeout: 252 seconds) |
| 2021-04-17 03:11:23 | → | elliott_ joins (~elliott_@pool-108-18-30-46.washdc.fios.verizon.net) |
| 2021-04-17 03:16:11 | <jaykru> | does anybody here have experience with crazy linker errors on arch linux? i've already enabled dynamic linking in my cabal config as suggested by the arch wiki. here's the full error i'm getting when building my project: https://commie.club/m/anNH |
| 2021-04-17 03:16:45 | <jaykru> | i have sdl2 and sdl2_gfx installed |
| 2021-04-17 03:20:02 | <sclv> | my recommendation is always not to use arch’s ghc and cabal and just install a clean normal toolchain with ghcup |
| 2021-04-17 03:20:04 | → | gnumonic joins (~gnumonic@c-73-170-91-210.hsd1.ca.comcast.net) |
| 2021-04-17 03:20:48 | <monochrom> | jaykru: https://wiki.archlinux.org/index.php/Haskell#Problems_with_linking |
| 2021-04-17 03:20:59 | <monochrom> | Oh nevermind, you already know. |
| 2021-04-17 03:21:18 | <monochrom> | Yeah please use ghcup and discard archlinux's packages. |
| 2021-04-17 03:24:28 | → | dyeplexer joins (~lol@unaffiliated/terpin) |
| 2021-04-17 03:25:42 | × | AkechiShiro quits (~AkechiShi@2a01:e0a:5f9:9681:2d2a:c15d:f996:c56f) (Quit: WeeChat 2.9) |
All times are in UTC.