kakadu has quit [Remote host closed the connection]
kor1 has joined #ocaml
elf_fortrez has joined #ocaml
Haudegen has quit [Quit: Bin weg.]
Haudegen has joined #ocaml
elf_fortrez has quit [Quit: Client closed]
Haudegen has quit [Quit: Bin weg.]
mbuf has joined #ocaml
dinosaure has quit [Quit: WeeChat 2.3]
dinosaure has joined #ocaml
waleee has joined #ocaml
Haudegen has joined #ocaml
<olle>
Everything is quiet
<olle>
Any updates about affinity types in OCaml this year?
<companion_cube>
Good question, did you work on them?
<olle>
^^
<olle>
I have no idea who works on what
<companion_cube>
No one, I think?
<olle>
Got it
mattil has joined #ocaml
mattil has quit [Remote host closed the connection]
mattil has joined #ocaml
glassofethanol has quit [Read error: Connection reset by peer]
glassofethanol has joined #ocaml
<olle>
companion_cube: One other question, about "Kindly bent to free us", is that a PhD dissertation?
<olle>
Maybe Drup knows better
adanwan has quit [Remote host closed the connection]
adanwan has joined #ocaml
<companion_cube>
that's Drup's thing
<companion_cube>
(and a music album)
neiluj has joined #ocaml
gravicappa has quit [Ping timeout: 268 seconds]
zebrag has joined #ocaml
<olle>
I noticed :)
<neiluj>
Hi! Wanted to override the behaviour of a module by adding fields in the main record type such as f: (int -> int) option;, functions that are called like so: Option.value t.f ~default:f_module) x
<neiluj>
that wouldn't work since OCaml is strict so t.f would be called even though it is None?
<companion_cube>
no it works
<neiluj>
ah nice then!
<companion_cube>
you get the function eagerly but it's only applied if selected
<companion_cube>
t.f is just a record access right?
<neiluj>
yes
wonko has joined #ocaml
wonko has quit [Ping timeout: 252 seconds]
olle has quit [Ping timeout: 272 seconds]
hackinghorn has quit [Quit: Leaving]
Tuplanolla has joined #ocaml
Haudegen has quit [Quit: Bin weg.]
neiluj has quit [Remote host closed the connection]
neiluj has joined #ocaml
spip has quit [Ping timeout: 240 seconds]
mbuf has quit [Quit: Leaving]
neiluj has quit [Read error: Connection reset by peer]
glassofethanol has quit [Quit: leaving]
Skyfire has quit [Ping timeout: 256 seconds]
Skyfire has joined #ocaml
Skyfire has quit [Ping timeout: 272 seconds]
average has joined #ocaml
mattil has quit [Read error: Connection reset by peer]
mattil has joined #ocaml
Haudegen has joined #ocaml
gravicappa has joined #ocaml
tjammer has joined #ocaml
spip has joined #ocaml
wonko has joined #ocaml
Skyfire has joined #ocaml
mattil has quit [Remote host closed the connection]
olle has joined #ocaml
eight has quit [Quit: leaving]
<olle>
Menhir is just Yacc, right? Or Bison?
<olle>
Hm, LR(1)
gravicappa has quit [Ping timeout: 248 seconds]
<d_bot>
<carmysilna> ocamlyacc is more like yacc, I think
ocabot has quit [Ping timeout: 258 seconds]
cedric has joined #ocaml
companion_cube has quit [Ping timeout: 268 seconds]
copy has quit [Ping timeout: 252 seconds]
ks_ has quit [Ping timeout: 250 seconds]
oisota has quit [Ping timeout: 268 seconds]
energizer has quit [Ping timeout: 272 seconds]
copy has joined #ocaml
<olle>
Right
ocabot has joined #ocaml
companion_cube has joined #ocaml
oisota has joined #ocaml
ks_ has joined #ocaml
energizer has joined #ocaml
<dh`>
ocamlyacc is practically cutpaste of traditional yacc, to the extent that for some reason inside the grammar comments are /* */ instead of (* *)
kor1 has quit [Ping timeout: 248 seconds]
<olle>
k
bartholin has quit [Quit: Leaving]
Serpent7776 has quit [Quit: leaving]
<companion_cube>
menhir is way better than (ocaml)yacc
<olle>
LR(1) too?
<companion_cube>
LALR? not sure, but not very important either
<companion_cube>
the tool is extremely good in practice, and very flexible
<olle>
No? Hm.
<d_bot>
<EduardoRFS> are out of heap pointers valid with `no-naked-pointers`?
<companion_cube>
probably not
<d_bot>
<EduardoRFS> even if it points to a valid ocaml block?
<companion_cube>
good question then
<companion_cube>
@EduardoRFS your comment on opam is going to trigger reactions, I think
<d_bot>
<EduardoRFS> I'm not trying to attack on opam there, but I'm expecting reactions
<companion_cube>
I know
<companion_cube>
but it's a sensitive topic I think
<d_bot>
<EduardoRFS> about the question, I'm almost there with my refcounting implementation in OCaml, figured out a way to handle the FFI. And now I wonder if I could have a heap outside of the OCaml GC which is only maintained by the ref counter
<companion_cube>
people have poured a lot of work into opam
<companion_cube>
a problem is that the GC expects to be able to move values, I think
<companion_cube>
it's a compacting GC
<d_bot>
<EduardoRFS> HMM, if that's the case I can probably hack my way into it, allowing the GC to fix the pointers in the refcounted heap
<companion_cube>
how do you handle inner values in the refcounted values
olle has quit [Ping timeout: 248 seconds]
<d_bot>
<EduardoRFS> the GC traverse the refcounted values normally, it just doesn't count it as a value to be moved. Then after moving it in place it already knows where the pointer should be and can fix the pointers on the refcounted values
<companion_cube>
oh, are you modifying the GC itself?
<d_bot>
<EduardoRFS> yup modifying also the header of values
<d_bot>
<EduardoRFS> at first I thought that it would be hard, but surprisingly the bits of code that are 26years old are really well done, so changing the value header was simple
<companion_cube>
that's cool
<companion_cube>
just be aware that multicore might change everything :s
<d_bot>
<EduardoRFS> then I found that FFI would be terrible because of Field(), but I added a tag on top of the header which marks a value if ever enters on the FFI and if a value has this tag marked the refcounter will be meaningless
<companion_cube>
what's your use case for refcounted values, btw?
<d_bot>
<EduardoRFS> yeah thinking about that, but I don't think there is anything on my current code that would be harder on multicore
<companion_cube>
(seems like FFI _should_ be easier with it?)
<companion_cube>
I just mean that the GC code has changed a lot
<d_bot>
<EduardoRFS> I'm looking on writing server for games, namely a minecraft server that is capable of handling BIG worlds with a lot of players, and when thinking about things I just noticed that the latency is still not as I would want, but I don't want to change my coding style completely
<d_bot>
<EduardoRFS> Plus, I'm really curious on what would happen to GC time and how does OCaml behave when changing the runtime drastically like this
<sadiq>
you can basically choose your latency with the existing GCs?
<sadiq>
the minor collection times are bounded by the size of the minor heap
<sadiq>
and the major collector is incremental
<sadiq>
just need to steer clear of compactions (which you can disable)
<companion_cube>
recently I've tried a bit some array programming, to push the perfs
<companion_cube>
and turns out bigarrays are really, really fast if used properly
<companion_cube>
(and have 0 GC cost)
<sadiq>
you could probably make the number (and size) of major slices adjustable. iirc there are two per minor collection at the moment.
<d_bot>
<EduardoRFS> on big heaps from what I understand it's not incremental as it seems, if I have an array which is 1gb long it will do the scanning on a single pass
<sadiq>
which version of ocaml are you using?
<sadiq>
there were a lot of changes in 4.09 or 4.10 to fix that very issue
<sadiq>
I know it shouldn't exist in 4.12
<companion_cube>
also hopefully it's a bigarray
<d_bot>
<EduardoRFS> hmmm that's interesting, not sure when was the last time I tried
<sadiq>
my changes in 4.12 for sure track the position inside blocks
xenu_ has joined #ocaml
<d_bot>
<EduardoRFS> is it also incremental over a big tree?
<sadiq>
yep
<d_bot>
<EduardoRFS> OH that's really nice
<d_bot>
<EduardoRFS> I also didn't knew it was possible to disable compacting, that's a nice to know feature
<sadiq>
Damien did a bunch of work a few years back
<d_bot>
<EduardoRFS> yeah saw this post, but didn't knew what was merged and what not
<d_bot>
<EduardoRFS> was aging also merged?
<sadiq>
no, aging wasn't worth the tradeoff apparently
<sadiq>
I know the array situation was there in 4.12, my colors change included a new mark stack.
<sadiq>
(and the mark stack is now shared by multicore, so that has the same property)
tjammer has quit [Quit: terminated!]
xenu_ is now known as xenu
<d_bot>
<EduardoRFS> interesting, looking on the colors change, remember seeing it but didn't knew it addressed this situation
<companion_cube>
@EduardoRFS I'd be curious to hear more on opam from you, btw
<d_bot>
<EduardoRFS> my main thing is that opam is not a sandboxed package manager, sometimes things just work on your computer, you commit it and it doesn't work on someone else computer
<d_bot>
<EduardoRFS> this is also a problem I had on the early days of npm which was drastically improved by yarn, but it's worse in OCaml as we rely a lot on tools present on the OS a couple of times just by accident
<sadiq>
(I must sleep though)
<d_bot>
<EduardoRFS> have a good night sadiq
<d_bot>
<EduardoRFS> also opam doesn't try to manage native deps, which makes not feasiable to achieve nice cross compilation. While esy does that just because it has sandboxing
<d_bot>
<EduardoRFS> which leads to cross compiling being quite simple to do in esy after you understand the problem
<d_bot>
<EduardoRFS> Which already works a lot better than opam-cross but it's still not a clean experience as I would like
<companion_cube>
for me it's the lockfiles, whicih might be better with 2.1 though
<companion_cube>
(I also wish there was only one lock file per project)
<d_bot>
<EduardoRFS> lockfiles is a nice beginning but you still suffer from the sandboxing part and not working nicely on Windows, but I think opam is also integrating cygwin for windows in the future
<companion_cube>
ah I see, for you sandboxing woudl include lockfiles
<companion_cube>
that does make sense
<d_bot>
<Deadrat> Windows works fine
<d_bot>
<Deadrat> With wsl2
<d_bot>
<EduardoRFS> yeah, that's not windows, that's literally a VM
<d_bot>
<Deadrat> Well, it's quite rare that someone would develop for windows specifically excluding desktop apps
<d_bot>
<EduardoRFS> yeah, I wouldn't say that rare but for me there is a more fundamental problem here, you're asking everyone to learn essentially how to use a new operating system on a VM, then you need integrations with your editor which are good but not always
<d_bot>
<Deadrat> Also in opam 2.1 switches are installed by lockfiles
<companion_cube>
you have to ask for lockfiles, right?
<d_bot>
<Deadrat> Just
<companion_cube>
and because the repo is not immutable, you can't rely on builds to work in the future :/
<d_bot>
<Deadrat> Opam lock
<d_bot>
<Deadrat> And then opam switch create . --locked on a fresh clone
average has quit [Quit: Connection closed for inactivity]
<d_bot>
<Deadrat> Works fine
<companion_cube>
I'd argue it's the wrong default
<companion_cube>
but then it should have been opam 3 probably
<d_bot>
<Deadrat> But I guess I'm weird
<d_bot>
<EduardoRFS> and you also cannot share the build cache in a safe manner, because it's not reproducible
<companion_cube>
I think part of the issue is OCaml itself, Eduardo, though
<companion_cube>
because it embeds paths
<d_bot>
<EduardoRFS> I personally don't use this feature a lot(16/32 FTW) but it's useful for template projects
<companion_cube>
@Deadrat you may be lucky and never had a dependency change under you
<d_bot>
<EduardoRFS> yes but esy works around that in a neat way, we do path rewriting
<companion_cube>
kind of neat :D
<companion_cube>
it's clever but it remains a hack
<d_bot>
<EduardoRFS> it's definitely a workaround, but OCaml is not the only package doing that, a couple packages suffer from this
<d_bot>
<Deadrat> Because I'm a hobby dev
<d_bot>
<Deadrat> No ocaml jobs
<d_bot>
<Deadrat> And I'm too dumb for js
<companion_cube>
we all are!
<d_bot>
<EduardoRFS> do you like blockchains?
cedric has quit [Quit: Konversation terminated!]
<d_bot>
<Deadrat> Can't say that I like them
<d_bot>
<EduardoRFS> sad
<d_bot>
<Deadrat> Because they are still
<d_bot>
<Deadrat> On my bucket list
<d_bot>
<Deadrat> To explore
<d_bot>
<Deadrat> Sometime in the future
<d_bot>
<Deadrat> So yeah
<d_bot>
<Deadrat> Out of the loop a bit
<d_bot>
<EduardoRFS> if you're looking for a job feel free to contact me, we do blockchain stuff in OCaml
<d_bot>
<Deadrat> I just do betting stuff like live feeds and bet processing
<d_bot>
<EduardoRFS> going back to the previous topic, I really think that OCaml could be a great language for multiplayer game servers.
<d_bot>
<EduardoRFS> where you want to have performance but also you control your hardware and how much memory you can use
<d_bot>
<Deadrat> It's a tough sell
<d_bot>
<Deadrat> Most people I know are strongly on the throw more hardware at the problem
<d_bot>
<EduardoRFS> yes but that doesn't scale for multiplayer gaming, you have essentially a server running at 2ghz with memory saturated and you have 10-50ms to get a tick
<d_bot>
<EduardoRFS> minecraft is an easy one, 50ms is the goal
<d_bot>
<EduardoRFS> but if you can go further you improve the pvp experience