<discocaml>
<otini_> `opam install ocaml-lsp-server odoc ocamlformat utop` doesn’t downgrade anything for me. There might be something wrong on your switch from the previous steps
<discocaml>
<dx3mod> Yes, thank you. I have already realised that I was wrong.
<discocaml>
<otini_> Ah yeah didn’t read the log properly. I’m still sleepy
<discocaml>
<dx3mod> Anyway, I have to be more careful not to make mistakes like that.
<discocaml>
<dx3mod> I made the same mistake recently. I added a dependency that I didn't need to. 🥲
<discocaml>
<otini_> Some ocaml packages are too strict with their upper version bounds, it’s annoying
olle has joined #ocaml
bibi_ has quit [Quit: Konversation terminated!]
bibi_ has joined #ocaml
alexherbo2 has joined #ocaml
srchdz has joined #ocaml
srchdz has left #ocaml [#ocaml]
bhoot has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
bhoot has joined #ocaml
bhoot has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
bhoot has joined #ocaml
<discocaml>
<lukstafi> It shouldn't anymore (since recently), 5.2 should be.
bhoot has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Guest28 has joined #ocaml
<discocaml>
<ada2k> the .net ecosystem is nice, but from what i've written in it the language is worse (awkward merging of c sharp oop with ocaml, no type aliases, etc)
<discocaml>
<ada2k> i don't think f# has first class modules either, and a lot of the big .net libraries seem to need you to write glue code in either c# or something that resembles it. i could get used to all of those things though, and the tooling and ecosystem for .net nowadays is pretty good
<discocaml>
<ada2k> @lukstafi have you used scala 3?
Guest28 has quit [Client Quit]
<discocaml>
<ada2k> i haven't written much more than a hello world in it, but looking at the language and ecosystem i would probably choose that over .net rn
<discocaml>
<lukstafi> No, sorry.
<discocaml>
<ada2k> was just curious 🙂
<discocaml>
<holmdunc> When I tried Scala 3, the build tooling seemed inscrutable and not very tastefully designed. Specifically things with names like Bleep and Bloop starting up compiler daemons behind my back because it's apparently too slow to run in a normal way?
bhoot has joined #ocaml
ggb has quit [Remote host closed the connection]
pluviaq has quit [Read error: Connection reset by peer]
henrytill has quit [Read error: Connection reset by peer]
_alix has quit [Remote host closed the connection]
kuruczgy has quit [Read error: Connection reset by peer]
soni_ has quit [Remote host closed the connection]
ursa-major has quit [Write error: Connection reset by peer]
sleepydog has quit [Remote host closed the connection]
xvilka has quit [Remote host closed the connection]
philipwhite has quit [Write error: Connection reset by peer]
pmk has quit [Write error: Connection reset by peer]
jmcantrell has quit [Write error: Connection reset by peer]
Ankhers has quit [Write error: Connection reset by peer]
whereiseveryone has quit [Read error: Connection reset by peer]
lane has quit [Write error: Connection reset by peer]
patrick_ has quit [Read error: Connection reset by peer]
rustyne has quit [Remote host closed the connection]
seeg has quit [Remote host closed the connection]
richardhuxton has quit [Remote host closed the connection]
immutable has quit [Remote host closed the connection]
ymherklotz has quit [Remote host closed the connection]
arya_elfren has quit [Read error: Connection reset by peer]
b0o has quit [Read error: Connection reset by peer]
pmk has joined #ocaml
lane has joined #ocaml
ggb has joined #ocaml
philipwhite has joined #ocaml
pluviaq has joined #ocaml
_alix has joined #ocaml
kuruczgy has joined #ocaml
patrick_ has joined #ocaml
whereiseveryone has joined #ocaml
ymherklotz has joined #ocaml
richardhuxton has joined #ocaml
ursa-major has joined #ocaml
arya_elfren has joined #ocaml
sleepydog has joined #ocaml
b0o has joined #ocaml
xvilka has joined #ocaml
henrytill has joined #ocaml
immutable has joined #ocaml
soni_ has joined #ocaml
jmcantrell has joined #ocaml
rustyne has joined #ocaml
seeg has joined #ocaml
Ankhers has joined #ocaml
alexherbo2 has quit [Remote host closed the connection]
bhoot has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
waleee has joined #ocaml
drakonis has quit [Quit: WeeChat 4.1.1]
drakonis has joined #ocaml
bhoot has joined #ocaml
drakonis has quit [Quit: WeeChat 4.1.1]
drakonis has joined #ocaml
bhoot has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<discocaml>
<deepspacejohn> In the, admittedly small, amount of time I spent with effects I mostly preferred using shallow ones. I'm not sure how I feel about deep ones getting syntax and shallows ones not (at least not yet). Maybe it doesn't really matter.
bhoot has joined #ocaml
motherfsck has joined #ocaml
bhoot has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
alexherbo2 has joined #ocaml
bhoot has joined #ocaml
myrkraverk has quit [Ping timeout: 260 seconds]
myrkraverk has joined #ocaml
bhoot has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
waleee has quit [Ping timeout: 260 seconds]
Anarchos has joined #ocaml
Tuplanolla has joined #ocaml
motherfsck has quit [Ping timeout: 252 seconds]
alexherbo2 has quit [Remote host closed the connection]
bhoot has joined #ocaml
germ has quit [Quit: ZNC 1.8.2+deb2build5 - https://znc.in]
dreadedfrog has quit [Ping timeout: 260 seconds]
olle has quit [Ping timeout: 248 seconds]
dreadedfrog has joined #ocaml
germ has joined #ocaml
motherfsck has joined #ocaml
<twobitsprite>
How frowned-upon are arrays in OCaml? Context: I'm thinking about writing a roguelike game, which means I'll need to keep a 2D list/array of tiles in the game, but a nested list seems like it would be inefficient
<companion_cube>
just go for it
<companion_cube>
(you can even have a flat array and access it with `x * width + y` or whatever)
<twobitsprite>
would that be more efficient? (I know, "premature optimization", but I'm trying to avoid the "FPS death" that games like Dwarf Fortress suffer from)
<companion_cube>
yeah it'd be more flat, more cache friendly
<twobitsprite>
ah, thanks
<discocaml>
<deepspacejohn> would a 2d bigarray generally have a performance difference compared to a regular array?
<discocaml>
<coolccat> For me, the main motivation is finding an ML dialect with a platform I’m more comfortable with. I’m more comfortable with the Java ecosystem but I’ve worked with .NET a bit
waleee has joined #ocaml
<companion_cube>
bigarray is nice if all you're storing is integers or floats
mbuf has quit [Quit: Leaving]
motherfsck has quit [Quit: quit]
dawids has joined #ocaml
dawids has quit [Remote host closed the connection]
bhoot has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<discocaml>
<ada2k> my experience of f# was that too much of it i was not writing ML but c# with weird syntax
<discocaml>
<ada2k> so just, if you have particular libraries in mind, check for actual functional bindings
<discocaml>
<ada2k> or honestly get more used to ocaml's tooling and working with c libraries inside ocaml
torretto_ has joined #ocaml
torretto has quit [Ping timeout: 260 seconds]
TCZ has joined #ocaml
Anarchos has quit [Quit: Vision[]: i've been blurred!]
<twobitsprite>
How mature/stable is multicore OCaml?
<twobitsprite>
And is it always going to be a separate project, or is the plan to eventually replace the mainline OCaml interpreter/compiler?
<discocaml>
<Kali> mature? not very, we only got it officially in december of 2022
<discocaml>
<Kali> with ocaml 5.0
<discocaml>
<Kali> it's already in ocaml
<twobitsprite>
Kali: ah, ok. But, say you're starting a new project as a part-time/hobby thing, would it be worth working on it now and hoping that it'll be relatively stable with some work-around-able caveats over the next few years?
<twobitsprite>
Kali: oh, then I guess I'm confused... I thought it was a separate project... I guess I need to read more about it
<discocaml>
<Kali> no, ocaml multicore was released with ocaml 5.0, and ocaml 5.0 was in development for 7 years; it wasn't some sort of separate project, just one of the things to get to ocaml 5
<discocaml>
<Kali> along with algebraic effects
<discocaml>
<Kali> as to the new project thing: as a general rule of thumb, ocaml progress is pretty slow, so you should be relatively safe
<discocaml>
<Kali> ocaml also doesn't make very many breaking changes, mostly just additions
<twobitsprite>
Kali: I mean moreso if I'm planning on using multicore features, it's not going to be unusably buggy or anything
<discocaml>
<Kali> ah, no
<discocaml>
<Kali> bugs in ocaml get fixed quickly
<discocaml>
<Kali> many of them have already been squashed between 5.0 and 5.2 (where we are now)
<twobitsprite>
cool... I guess next question is, do you know the best way to install ocaml 5 on Debian? Bookworm only has 4.13
<discocaml>
<Kali> don't install ocaml from your package manager
<twobitsprite>
source?
<discocaml>
<Kali> use the opam installation script on the opam website
<twobitsprite>
ahh, ok, thanks
<twobitsprite>
does that support user installations, or does it require installing to /usr ?
<discocaml>
<Kali> package managers always lag behind and you need to install opam anyway if you want to install ocaml packages
<discocaml>
<Kali> user installations, yes, it just downloads the correct opam binary and puts it where you tell it to
<discocaml>
<ada2k> twobitsprite: if the debian opam package doesn’t depend on ocaml you can use that too
<discocaml>
<._null._> (even if it does, you'd just make a switch with not the system compiler)
<discocaml>
<ada2k> i think debian doesn’t depend but it’s been a bit since i’ve used it on my dev machine
<discocaml>
<ada2k> your opam version might be a bit old though
TCZ has quit []
<twobitsprite>
and if I distribute a binary compiled with ocamlc, the user doesn't need to install ocaml at all, let alone a specific version, right? I.e, the runtime is included in the compiled binary?
<twobitsprite>
sorry for all the dumb questions, I really appreciate the help
<discocaml>
<dx3mod> )
<discocaml>
<Kali> compiled ocaml, regardless of bytecode or native, does not need any external ocaml installation or libraries
<discocaml>
<Kali> so yes you can just distribute the binary
<discocaml>
<Kali> as far as i know
<discocaml>
<octachron> Bytecode executable needs an installation of the runtime to run
<discocaml>
<Kali> oh, nevermind then
<discocaml>
<Kali> then bytecode (ocamlc) needs a distribution of `ocamlrun` to run the executable, i guess
<discocaml>
<Kali> but not native?
chrisz has joined #ocaml
<discocaml>
<octachron> Yes, native executable are OS executables (with the OCaml runtime linked statically). Contrarily, someone has to provide the bytecode interpreter to run bytecode executable.
<twobitsprite>
oh, right, I mixed up ocamlc and ocamlopt, but yeah, you answered my questions, thanks!
<discocaml>
<dx3mod> Average source-based package manager experience :ocaml:
<discocaml>
<Kali> yeah, ocaml takes a long time to install the first time
<twobitsprite>
I wasn't complaining, I've done Linux From Scratch, I just wasn't expecting it to compile everything from source... OS package managers have me spoiled :P
TCZ has joined #ocaml
bartholin has quit [Quit: Leaving]
torretto has joined #ocaml
torretto_ has quit [Ping timeout: 260 seconds]
pie_ has quit []
<discocaml>
<ada2k> twobitsprite: same. nix has some system to share compiler binaries but i've never used it. i just want 5 in distros
<discocaml>
<ada2k> oo,, 5.2.0 is in debian experimental