dnh has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Tuplanolla has quit [Ping timeout: 255 seconds]
habnabit_ has quit [Read error: Connection reset by peer]
habnabit_ has joined #ocaml
John_Ivan has quit [Ping timeout: 276 seconds]
mal``` has joined #ocaml
mal`` has quit [Ping timeout: 245 seconds]
<discocaml>
<sixilli> I'm wondering why does the LSP the ability to get type information? For some reason some functions when I do `K` I get back `no information available`
<discocaml>
<sixilli> I'm using ocaml lsp and I have `dune build --watch` running as well.
<discocaml>
<sixilli> But if I do `K` on line 10 it shows the correct type information.
<discocaml>
<darrenldl> interesting numbering : p
<discocaml>
<darrenldl> so the entire project compiles/is well typed?
<discocaml>
<sixilli> Yeah function definitions show the correct types, but it seems to be unable to infer them from inside the function bodies?
<discocaml>
<sixilli> The weird part is it's very hit or miss what works and what doesn't. For instance `parse_return` on line 7 works fine.
<discocaml>
<darrenldl> (havent used lsp enough/at all, so just gonna leave to others)
<discocaml>
<Kali> the line number that the cursor is on is absolute, and the numbers outside are relative
<discocaml>
<Kali> it's more common in vim derivatives where there are relative jump commands
<discocaml>
<darrenldl> ah i see
<discocaml>
<darrenldl> hm interesting
<discocaml>
<sixilli> I kinda figured out my issues. After strongly typing a function I uncovered some bugs in something that I was in the process of implementing that kinda made the LSP hallucinate types. I've now removed the hard coded types and things are working again.
<discocaml>
<sixilli> jk I lied. I do need the hard typing of I get weird compile errors
waleee has quit [Ping timeout: 255 seconds]
<companion_cube>
ok I'm getting confused by how to measure, in a benchmark, how much the benchmarked thing allocates
<companion_cube>
I've tried using `Gc.counters()` before and after running it in a loop, and dividing by n (number of iterations)
<companion_cube>
but it seems… fishy, because in one case I get an allocation rate that seems impossible to me (producing a 200kB string in less than 200kB alloc)
<greenbagels>
I'm still after all this time unused to being constrained so much by standard libraries being fast and light; what would be people's suggestions for a container to hold an ordered list that can be quickly shuffled?
<greenbagels>
Defining a random access list myself?
habnabit_ has joined #ocaml
<companion_cube>
turn it into an array?
bartholin has joined #ocaml
<discocaml>
<'a patate> Just read some pages on the ocaml wiki, and there are some problems...
<discocaml>
<'a patate> - formated code ( \`\`\`ocaml) is broken most of the time
<discocaml>
<'a patate> what is it generated from?
<discocaml>
<octachron> Looks at the history.
<discocaml>
<'a patate> I don't think I see what you want me to see...
dnh has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<discocaml>
<._null._> Most edit histories are one commit long, all have the exact author and all span a few days. For a wiki with that many pages, it can't have been written by hand. Also, the quality of the text indicates AI generation
dnh has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<discocaml>
<'a patate> That feels seriously wrong.
<discocaml>
<'a patate> But using AI to confuse newcomers sure would be an efficient technique.
<discocaml>
<contextfreebeer> Lol
dnh has joined #ocaml
dnh has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
dnh has joined #ocaml
dnh has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
wingsorc has quit [Ping timeout: 268 seconds]
dnh has joined #ocaml
dnh has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
waleee has quit [Ping timeout: 268 seconds]
szkl has joined #ocaml
<discocaml>
<darrenldl> ah it has annoying/malicious redirects to ads now too, wonderful
<discocaml>
<stab.__> Been trying to use containers instead of my more typical Base setup. Is there a convenient way to do hash functions? ppx_hash is baked into the the Jane ecosystem. I see the containers has combinators but they don't really help if ur say writing a hash function for a tree like variant
<companion_cube>
For a tree you'd have to write a little recursive function
<discocaml>
<stab.__> Yeah but I guess my point is combinators don't really play nicely with writing a recursive function so I'm just kinda by hand writing a repetitive recursive function when compared with ppx deriving etc
<discocaml>
<stab.__> I mean if it's what I gotta do it's what I gotta do just wondering if I'm missing something
<discocaml>
<stab.__> (long story short I want nodes in a graph that are representing terms of an AST)
<discocaml>
<stab.__> I guess maybe I could provide my own runtime lib for the Jane ppx but I'm not sure how well that would work
<companion_cube>
You could write a ppx
<companion_cube>
The combinators are enough for the runtime part
<companion_cube>
Are you trying to do hashconsing?
szkl has quit [Quit: Connection closed for inactivity]
<discocaml>
<stab.__> Nah I'm trying to write a really dumb EUF solver and I need to lookup nodes in a graph by the term they are representing
<discocaml>
<stab.__> Ie. f(f(x)) etc. working on the explanation part of the congruence closure
<discocaml>
<stab.__> Want to store a forest of union operations between terms so we know how we got here
<companion_cube>
Right, but once you're in the congruence closure each node really should have a unique integer id
<companion_cube>
So you can hash it trivialize
<companion_cube>
Trivially
<discocaml>
<stab.__> Yeah but underlying the graph I want to map the term to it's nodeid
<discocaml>
<stab.__> Hence the hash
<discocaml>
<stab.__> There might be a better way to do it to be fair
<discocaml>
<stab.__> I'm not necessarily trying to be efficient this is just an exercise of writing an smt solver over thanksgiving lol
<companion_cube>
When you add a term, you add its subterm first, so they have a congruence closure node
<companion_cube>
You can use the id of these as a hash for the subterms
<companion_cube>
Lol yeah good luck :D
<companion_cube>
Are you basing yourself on an existing SAT solver?
<discocaml>
<stab.__> Nah I wrote the dpll solver earlier this week and then generalized it to a theory signature
<companion_cube>
Fun stuff
<discocaml>
<stab.__> Now trying to implement the EUF theory
<companion_cube>
Yeah, I see. Are you following any specific paper?
<discocaml>
<stab.__> Yeah I'm having fun with it. Goal is to have a full self contained implementation of a basic weakest preconditions prover for a toy lang
<discocaml>
<stab.__> Just nelson oppen congruence closures then got stuck on explanation
<companion_cube>
Damn that's ambitious :)
<companion_cube>
You could read the classic "simplify" paper
<discocaml>
<stab.__> Yeah Ive been looking at a paper proof producing congruence closures for some help on dealing with that efficiently which is what I'm implementing now
chrisz has quit [Quit: leaving]
gwizon has joined #ocaml
gwizon has quit [Quit: leaving]
John_Ivan has joined #ocaml
justThanks is now known as justache
gwizon has joined #ocaml
<companion_cube>
The oliviera one?
<companion_cube>
(iirc)
<discocaml>
<stab.__> Yep that one
<discocaml>
<stab.__> Reasonably convenient for me cause I can adapt the congruence closure stuff I already have pretty easily
<discocaml>
<stab.__> Yep I've seen sidekick I think definitely beyond what Im going for here. Trying for the simplest everything
<discocaml>
<stab.__> Not looking forward to handling e-matching cause that'll be a thing
<companion_cube>
:D well the simplify paper has you covered
<companion_cube>
it's one of the seminal papers of SMT solving
<discocaml>
<stab.__> Cool I'll have to bookmark it, we'll see when I get there. Not sure how it works i just remember roughly... match quantifier and instantiate but idk how you make that fit in with ur lazy solver
<discocaml>
<stab.__> But I want euf with dumb quantifiers so I guess I'll be finding out
<companion_cube>
yeah you match quantifiers and then instantiate, that's it
<tremon>
hi all, anyone know how I can get the file descriptor behind an eio Flow?
<companion_cube>
not sure you can in general, not all flows are FDs afair
<companion_cube>
(some might be user defined)
<tremon>
hmm, ok, more specific then :)
<tremon>
I have a local unix socket, handling clients via run_server
<tremon>
I want to get the peer credentials of the connected clients, and I can instrument those calls myself, but not if I don't know the relevant file descriptor handle
dnh has joined #ocaml
<companion_cube>
it doesn't give you that? uh
<tremon>
maybe it does, but I don't know how to get it
<tremon>
the eio documentation isn't the most extensive I've come across
<companion_cube>
it's not 1.0 yet…
<tremon>
I know
<companion_cube>
there's this "tag" thing now… hmm
<companion_cube>
`type 'a connection_handler = 'a stream_socket -> Sockaddr.stream -> unit`
<companion_cube>
isn't your handler given a sockaddr?
<tremon>
yes, but the sockaddr type is `Unix of string
<tremon>
unless there are private fields I can't access, there's no room there for storing a file descriptor
<companion_cube>
hu. is that like addr:port?
<companion_cube>
oh sorry, you want the FD, right
<companion_cube>
idk, just ask on the bugtracker
<tremon>
yes, for tcp/udp it's Ipaddr*int
<companion_cube>
oh, right, you're using unix sockets? cool
<tremon>
thanks so far, I'll add some more tracing, see if I can get something that looks like a file descriptor, otherwise I'll raise a github issue (I presume that's the bugtracker you referred to)
<companion_cube>
Yep
Serpent7776 has quit [Ping timeout: 240 seconds]
bibi_ has quit [Quit: Konversation terminated!]
bibi_ has joined #ocaml
<discocaml>
<stab.__> I'll have to look into what this "It used to provide a functorized interface, but it now comes with its own representation of terms, in a simple version of the Calculus of Constructions. Users can extend that term representation by adding new custom constants" looks like sometime. Currently I have terms functorized but it's kinda a pain
bartholin has joined #ocaml
<companion_cube>
Ahah yeah it's a massive pain in my experience
dnh has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
dnh has joined #ocaml
Serpent7776 has quit [Ping timeout: 245 seconds]
infinity0_ has joined #ocaml
infinity0 is now known as Guest3335
Guest3335 has quit [Killed (zinc.libera.chat (Nickname regained by services))]
infinity0_ is now known as infinity0
infinity0 has quit [Ping timeout: 260 seconds]
bartholin has quit [Quit: Leaving]
dnh has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
wingsorc has joined #ocaml
John_Ivan has quit [Quit: Disrupting the dragon's slumber one time too often shall eventually bestow upon all an empirical and indiscriminate conflagration that will last for all goddamn eternity.]
John_Ivan has joined #ocaml
<greenbagels>
companion_cube: re: shuffling a list, yeah i suppose an array would be the best bet, and shuffle things in-place; i guess i was thinking about a more list-like structure
soni has quit [Killed (lead.libera.chat (Nickname regained by services))]
SoniEx2 is now known as Soni
soni_ has joined #ocaml
<Soni>
y'know what's annoying? we haven't been able to talk to soni_ about the nick thing
<Soni>
maybe they like getting /nickserv regain'd but we're very much open to talking about it and seeing if we can reach a solution/an agreement
<greenbagels>
Soni: hm?
<Soni>
greenbagels: yes?
<greenbagels>
just confused about your comment
<Soni>
greenbagels: which part?
<greenbagels>
relevance, i suppose
<greenbagels>
is there a nickname dispute between the two of you?
<Soni>
ah right
<Soni>
* [Whois] soni_ is a user on channels: #ocaml
<Soni>
only channel in common/only channel we know them to be in
<Soni>
not so much a dispute - we've had "Soni" registered with nickserv for as long as we've been on libera
<Soni>
more "we actually do not enjoy using /nickserv regain on actual ppl" so we would really rather get this resolved on friendly terms somehow