Newest at the top
2024-05-04 21:42:37 +0200 | <erty> | wait I just sudo purged cuda 12, let me reinstall it back |
2024-05-04 21:42:13 +0200 | <tomsmeding> | right |
2024-05-04 21:42:08 +0200 | <tomsmeding> | if it works at all, it would need to go in extra-deps in stack.yaml together with the overrides for accelerate-* |
2024-05-04 21:42:02 +0200 | <erty> | yes and stack.yaml https://paste.tomsmeding.com/nnFY5ChD |
2024-05-04 21:41:35 +0200 | <tomsmeding> | erty: that's a package.yaml file |
2024-05-04 21:41:33 +0200 | stiell_ | (~stiell@gateway/tor-sasl/stiell) |
2024-05-04 21:41:03 +0200 | <tomsmeding> | I didn't try with stack, you might have luck adding that language-c PR to extra-deps |
2024-05-04 21:40:56 +0200 | <erty> | https://paste.tomsmeding.com/1zGj4NjY |
2024-05-04 21:40:48 +0200 | <tomsmeding> | I see, I thought you were using cabal because you accepted my cabal.project :p |
2024-05-04 21:40:38 +0200 | <erty> | I am using stack |
2024-05-04 21:40:29 +0200 | <tomsmeding> | erty: are you using cabal or stack? |
2024-05-04 21:40:22 +0200 | <erty> | tomsmeding: you mean adding that package as a dependency in extra-deps? |
2024-05-04 21:39:58 +0200 | stiell_ | (~stiell@gateway/tor-sasl/stiell) (Ping timeout: 260 seconds) |
2024-05-04 21:38:22 +0200 | <tomsmeding> | erty: but just adding that language-c PR as a source-repository-package will not work (if it does for you please let me know, but it didn't for me) because language-c is a dependency of a build-tool dependency of the 'cuda' package, instead of a normal (transitive) dependency, and source-repository-package clauses seem to override only normal (transitive) dependencies |
2024-05-04 21:36:59 +0200 | <mauke> | I *was* wondering where that unpackCStringAscii# came from |
2024-05-04 21:36:46 +0200 | <mauke> | {-# RULES "TEXT literal" forall a. pack (GHC.unpackCString# a) = unpackCStringAscii# a #-} |
2024-05-04 21:36:44 +0200 | <tomsmeding> | mauke: it's text, what did you expect |
2024-05-04 21:36:31 +0200 | stiell | (~stiell@gateway/tor-sasl/stiell) |
2024-05-04 21:36:25 +0200 | <erty> | ok i'll try |
2024-05-04 21:36:20 +0200 | <tomsmeding> | mauke: of course :) |
2024-05-04 21:36:10 +0200 | <mauke> | tomsmeding: ooh, I see what it's doing! it's cheating with RULEs |
2024-05-04 21:35:22 +0200 | <tomsmeding> | erty: the relevant issue is here https://github.com/visq/language-c/pull/94 |
2024-05-04 21:34:50 +0200 | <erty> | *more |
2024-05-04 21:34:50 +0200 | stiell | (~stiell@gateway/tor-sasl/stiell) (Ping timeout: 260 seconds) |
2024-05-04 21:34:47 +0200 | <erty> | *mode |
2024-05-04 21:34:38 +0200 | <erty> | tomsmeding: I tried to do that but Nvidia updates cuda 11 to cuda 12 automatically. But let me try one for time |
2024-05-04 21:34:31 +0200 | <tomsmeding> | I forget if there is a fix for cuda 12 |
2024-05-04 21:33:49 +0200 | <tomsmeding> | erty: the ""easiest"" solution is to downgrade to cuda 11 |
2024-05-04 21:32:36 +0200 | <tomsmeding> | ah that error |
2024-05-04 21:32:01 +0200 | <erty> | https://paste.tomsmeding.com/iFiLTshf |
2024-05-04 21:31:32 +0200 | stiell_ | (~stiell@gateway/tor-sasl/stiell) |
2024-05-04 21:31:29 +0200 | <erty> | tomsmeding: Thanks for providing config for Accelerate package yesterday. I used your config file but it gives me error for which I can't find a way to resolve. I use ghc (9.4.8),stack (2.13.1), cuda 12 and llvm15. |
2024-05-04 21:31:12 +0200 | <raehik> | oh GOD that's another package |
2024-05-04 21:31:06 +0200 | <raehik> | I'm hopefully gonna ignore almost all of this anyway since I realized I can do it on the type-level. just need a type-level Show |
2024-05-04 21:30:02 +0200 | <tomsmeding> | but it's just a buffer copy, which cpu's are good at |
2024-05-04 21:29:48 +0200 | Square | (~Square@user/square) |
2024-05-04 21:29:44 +0200 | <tomsmeding> | huh, seems there's a buffer copy involved even with new text (it uses Data.Text.unsafeCStringAscii# https://hackage.haskell.org/package/text-2.1.1/docs/src/Data.Text.Show.html#unpackCStringAscii%23 ) |
2024-05-04 21:29:42 +0200 | stiell_ | (~stiell@gateway/tor-sasl/stiell) (Ping timeout: 260 seconds) |
2024-05-04 21:28:40 +0200 | <raehik> | (actually considering cheating via ShowType*) |
2024-05-04 21:28:26 +0200 | <raehik> | tomsmeding: I actually considered lol. it might be faster than doing it properly with Div/Mod |
2024-05-04 21:28:02 +0200 | <tomsmeding> | mauke: it doesn't, but it can use a function that rewrites away very nicely against GHC.CString.unpackCString# |
2024-05-04 21:27:31 +0200 | <raehik> | tomsmeding: hrm interesting on Text point. idk I guess I'll check later, but I'm being less afraid of IsString for ergonomics' sake |
2024-05-04 21:27:25 +0200 | <mauke> | still, the fromString code doesn't have access to that representation |
2024-05-04 21:27:16 +0200 | <tomsmeding> | mauke: https://play.haskell.org/saved/sEA1hrVK look at the M.foo1 and foo definitions at the top of the core |
2024-05-04 21:26:24 +0200 | stiell | (~stiell@gateway/tor-sasl/stiell) |
2024-05-04 21:26:22 +0200 | <mauke> | ooh |
2024-05-04 21:26:03 +0200 | <tomsmeding> | iirc, GHC actually compiles string literals to utf8 buffers in the executable, which it then reads at runtime to produce the heap-allocated String |
2024-05-04 21:26:00 +0200 | <mauke> | if there is no String in the resulting code, it has to do some sort of encoding at compile time |
2024-05-04 21:25:32 +0200 | <mauke> | String is Unicode |
2024-05-04 21:25:16 +0200 | rvalue- | rvalue |