2026/02/04

Newest at the top

2026-02-04 16:25:13 +0100Inline(~User@2a02:908:1246:26e0:e780:60f2:d5f3:ea13) (Quit: KVIrc 5.2.6 Quasar http://www.kvirc.net/)
2026-02-04 16:24:24 +0100 <haskellbridge> <Morj> But can I build using ghc with mcabal?
2026-02-04 16:19:54 +0100petrichor(~jez@user/petrichor) (Quit: ZNC 1.10.1 - https://znc.in)
2026-02-04 16:17:34 +0100tydes(~tydes@user/ttydes) ttydes
2026-02-04 16:10:50 +0100 <mesaoptimizer> also any package that involves networking seems to throw an error
2026-02-04 16:10:35 +0100 <mesaoptimizer> any package that depends on ghc-prim cannot be installed via mcabal
2026-02-04 16:10:23 +0100 <mesaoptimizer> IIRC it couldn't build aeson for example, because that relied on ghc-prim
2026-02-04 16:09:57 +0100 <mesaoptimizer> microhs + mcabal cannot yet install / build most hackage packages
2026-02-04 16:09:31 +0100trickard_(~trickard@cpe-61-98-47-163.wireline.com.au)
2026-02-04 16:09:17 +0100trickard(~trickard@cpe-61-98-47-163.wireline.com.au) (Read error: Connection reset by peer)
2026-02-04 16:06:59 +0100noctux(~noctux@user/noctux) noctux
2026-02-04 16:04:28 +0100 <gentauro> Morj: Got it
2026-02-04 16:01:55 +0100 <haskellbridge> <Morj> I wanted to suggest memorizing that ($) is zero and using that as a mnemonic =)
2026-02-04 16:01:30 +0100 <dutchie> i always have to :i $ in ghci to see whether low number is tight binding or not
2026-02-04 16:00:40 +0100 <dutchie> why can I never remember which way the numbers go in fixity declarations
2026-02-04 15:59:58 +0100 <haskellbridge> <Morj> I could create an array of size 33 padded with zeroes, true, but it's even less convenient to use - there is no simple conversion from size 33 to size 32
2026-02-04 15:57:19 +0100 <haskellbridge> <Morj> If it were just Box<[u8]>, this could be achieved very simply. If it were [u8; 32] to append a byte and get [u8; 33] - also very simple. But I wanted to write one function for several N sizes
2026-02-04 15:56:33 +0100 <haskellbridge> <Morj> I wanted to write this function because I have arrays of different sizes (for XOF seeding), and the algorithm wants to append one or two bytes to the seeds sometimes
2026-02-04 15:55:57 +0100 <haskellbridge> <Morj> In rust you can have a choice between statically and dynamically known sizes, roughly [u8; N] and Box<[u8]>
2026-02-04 15:55:35 +0100 <gentauro> And you end up padding/populating non-used array items with some value.
2026-02-04 15:54:54 +0100 <gentauro> Morj: I noticed myself that Rust needs to know (statically) the size of arrays. Don't you end up by using a fixed buffer size and then just iterate?
2026-02-04 15:49:05 +0100 <akegalj> magic_rb: found this https://mail.haskell.org/pipermail/beginners/2010-October/005571.html
2026-02-04 15:49:04 +0100noctux(~noctux@user/noctux) (Ping timeout: 246 seconds)
2026-02-04 15:39:55 +0100 <merijn> I mean, that's kinda easy, just turn into ByteString and use attoparsec and/or binary :p
2026-02-04 15:38:32 +0100 <haskellbridge> <magic_rb> i wrote a fat32 filesystem driver in haskell for my thesis, it was an experience
2026-02-04 15:38:20 +0100 <haskellbridge> <magic_rb> my condolences
2026-02-04 15:33:43 +0100 <haskellbridge> <Morj> *with in haskell
2026-02-04 15:33:26 +0100 <haskellbridge> <Morj> «I have a [Word8] that I would like to convert to a Word32 in big endian. How can I do that?» - type shit that I have to deal with haskell
2026-02-04 15:33:18 +0100 <haskellbridge> <Morj> I think it's gc. I was rather talking about not having a big runtime, the environment is rather memory constrained
2026-02-04 15:32:33 +0100 <haskellbridge> <magic_rb> or does it do refcounting
2026-02-04 15:32:26 +0100 <haskellbridge> <magic_rb> microhs still does gc no?
2026-02-04 15:32:17 +0100 <haskellbridge> <Morj> Although, performance..
2026-02-04 15:31:27 +0100 <haskellbridge> <Morj> Hm, actually microhs might fit there, need to evaluate
2026-02-04 15:31:12 +0100 <haskellbridge> <magic_rb> :(
2026-02-04 15:31:06 +0100 <haskellbridge> <Morj> «just, give me haskell thank you very much» yeh. Except I currently have to write a thing without gc or a large runtime at all
2026-02-04 15:30:41 +0100 <haskellbridge> <magic_rb> honestly the only reason i may personally choose rust over haskell is due to the library ecosystem. for embedded i would try microhs, though idk how well that would work
2026-02-04 15:30:29 +0100 <haskellbridge> <Morj> If this were in rust, some problems of async runtimes would be removed
2026-02-04 15:30:22 +0100Enrico63(~Enrico63@148.252.128.12) Enrico63
2026-02-04 15:30:11 +0100 <haskellbridge> <Morj> I'm partial to the RIO approach of having only one monad, but you parameterize the context you read from it
2026-02-04 15:29:57 +0100 <haskellbridge> <magic_rb> just, give me haskell thank you very much
2026-02-04 15:29:50 +0100 <haskellbridge> <magic_rb> and a GC
2026-02-04 15:29:39 +0100 <haskellbridge> <Morj> And monad readers
2026-02-04 15:29:12 +0100 <haskellbridge> <Morj> «what features would you like to see in rust» I want `pub fn append_byte<const N: usize>(array: [u8; N], b: u8) -> [u8; N + 1]` to compile
2026-02-04 15:25:58 +0100 <lucabtz> yeah they missed a chance with do notation maybe
2026-02-04 15:25:43 +0100 <haskellbridge> <magic_rb> things get so much more awkward with those imo
2026-02-04 15:25:23 +0100 <haskellbridge> <magic_rb> not having actual do notation with Monads is to me a deal breaker
2026-02-04 15:25:07 +0100 <haskellbridge> <magic_rb> in 99% of cases i dont give a rats ass about not having a GC and having to fight the borrow checker or sprinkle Arc<> absolutely everywhere is not what i want to be doing
2026-02-04 15:25:03 +0100 <lucabtz> and for future
2026-02-04 15:25:03 +0100 <merijn> If you can afford GC then something like Haskell, Scala, any ML will give you essentially all the stuff you want
2026-02-04 15:24:45 +0100 <lucabtz> it kinda has do notation, but only for Option and Result