<d_bot>
<NULL> This one cheats to some extent, it looks at the underlying object representation of the exception, which happens to contain its name. This won't work for the arguments of the exceptions
<d_bot>
<idnes> here theres the speed of the bytecode interpreter listed
<d_bot>
<idnes> when is it applicable? i mean, at what stage
<d_bot>
<idnes> is the bytecode interpreter present in each execution? or just during some compilation?
<d_bot>
<idnes> ahhh nvm, now i understand
<d_bot>
<idnes> so source is compiled to bytecode, which then can be either compiled to native or used directly in the vm
rgrinberg has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
waleee has quit [Ping timeout: 256 seconds]
<d_bot>
<darrenldl> @NULL didnt quite expect why3 to not be in dune
<d_bot>
<NULL> I guess it just didn't make the transition
<d_bot>
<darrenldl> mclovin: interesting, seems like a nice christmas exercise maybe hmmmm
berberman_ has joined #ocaml
berberman has quit [Ping timeout: 240 seconds]
chrisz has quit [Ping timeout: 245 seconds]
chrisz has joined #ocaml
spip has joined #ocaml
Guest5247 has quit [Ping timeout: 256 seconds]
spip is now known as Guest9141
mbuf has joined #ocaml
<d_bot>
<minimario> what are some small project ideas that can be done in like a day (ofc that are particularly ocaml-friendly)
<d_bot>
<minimario> feeling a desire to hack some ocaml but don't have immediate ideas on what to hack hehe
<d_bot>
<minimario> like a mini ray tracer for example (except i did a bit of that a while back)
<companion_cube>
a mini type checker?
<d_bot>
<minimario> haha yeah that type of thing, except i was asked to do that for an assignment in a uni class xd
kaph has joined #ocaml
gravicappa has joined #ocaml
Serpent7776 has quit [Read error: Connection reset by peer]
Serpent7776 has joined #ocaml
rgrinberg has joined #ocaml
Haudegen has joined #ocaml
kaph has quit [Read error: Connection reset by peer]
sagax has joined #ocaml
kaph has joined #ocaml
zebrag has quit [Quit: Konversation terminated!]
gravicappa has quit [Ping timeout: 256 seconds]
kaph has quit [Ping timeout: 240 seconds]
kaph has joined #ocaml
mro has joined #ocaml
kaph has quit [Remote host closed the connection]
nv1234 has joined #ocaml
mro has quit [Remote host closed the connection]
mro has joined #ocaml
salkin has joined #ocaml
nv1234 has quit [Quit: Client closed]
jlrnick has joined #ocaml
jlrnick has quit [Ping timeout: 256 seconds]
tomku[m] has quit [Quit: You have been kicked for being idle]
mro has quit [Remote host closed the connection]
mro has joined #ocaml
gravicappa has joined #ocaml
mro has quit [Remote host closed the connection]
mro has joined #ocaml
rgrinberg has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
bartholin has joined #ocaml
jlrnick has joined #ocaml
mro has quit [Remote host closed the connection]
mro has joined #ocaml
mro has quit [Remote host closed the connection]
mro has joined #ocaml
mro has quit [Remote host closed the connection]
jlrnick has quit [Remote host closed the connection]
jlrnick has joined #ocaml
mro has joined #ocaml
mro has quit [Remote host closed the connection]
Tuplanolla has joined #ocaml
jlrnick has quit [Remote host closed the connection]
mro has joined #ocaml
jlrnick has joined #ocaml
rgrinberg has joined #ocaml
kakadu has joined #ocaml
jlrnick has quit [Remote host closed the connection]
mro has quit [Remote host closed the connection]
rgrinberg has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
mro has joined #ocaml
<d_bot>
<Et7f3> Reimplement a ocaml module ? Like list
<d_bot>
<Et7f3> Probably already done in uni. So a mini dune.
Anarchos has joined #ocaml
mro_ has joined #ocaml
mro_ has quit [Remote host closed the connection]
mro has quit [Ping timeout: 260 seconds]
mro has joined #ocaml
mro has quit [Remote host closed the connection]
kaph has joined #ocaml
kaph has quit [Read error: Connection reset by peer]
kaph has joined #ocaml
<d_bot>
<josé> \🐫
kaph has quit [Read error: Connection reset by peer]
kaph has joined #ocaml
kaph has quit [Ping timeout: 256 seconds]
kaph has joined #ocaml
jlrnick has joined #ocaml
kaph has quit [Ping timeout: 268 seconds]
kaph has joined #ocaml
kaph has quit [Read error: Connection reset by peer]
kaph has joined #ocaml
Haudegen has quit [Quit: Bin weg.]
jlrnick has quit [Ping timeout: 240 seconds]
<d_bot>
<let Butanium = raise Not_found;;> If you didn't already do it reimplementing the list is a good training
kaph has quit [Ping timeout: 256 seconds]
<d_bot>
<let Butanium = raise Not_found;;> You can also try to implement heap
<d_bot>
<let Butanium = raise Not_found;;> Then heapsoft
<d_bot>
<VPhantom> If someone familiar with `Bigarray` sees this: how are they freed? If I create an initial one, then extract a sub (say, to hand off to some async I/O function) and immediately let my initial full-size one fall out of scope. I assume that the original fixed memory area will remain intact until the sub also falls out of scope, somehow, and _then_ it will be freed when the GC collects the sub?
<d_bot>
<VPhantom> I perused the implementation but it's my first venture on the C side of the runtime and I can't see how that's managed.
<d_bot>
<KW78> In think it is on the GC side with finalizers and I assume Ref Counting
kaph has joined #ocaml
mro has joined #ocaml
<d_bot>
<VPhantom> I see. Since Bigarrays aren't records (I think?) but rather something from the C side, to me all bets were off as to how the ref counting was managed. I just wanted to make sure that it is safe to let the original, full-size instance fall out of scope after handing off a smaller "window" to something else.
<d_bot>
<VPhantom> Yeah that's the function I was looking at, but with the macros and conventions I'm totally unaware of, I don't understand much of it.
<d_bot>
<VPhantom> It's especially unclear to me how the allocated sub retains a pointer to the original allocated area.
<d_bot>
<VPhantom> Ah update proxy near the end of the sub function, i see.
<d_bot>
<KW78> Proxy on Heap -> GCed -> finalizer if refcout = 0 -> free
<d_bot>
<KW78> Now I just looked at the code I am not a specialist (but I have some notion of how the GC works)
<d_bot>
<VPhantom> Sounds good to me. It's the proxy business I had failed to notice. 😉
<d_bot>
<VPhantom> It's funny, I never did this with other languages but with OCaml I can dive right into the source code to get most of the answers I'm looking for, and not feel too lost.
<d_bot>
<KW78> me too !
<d_bot>
<VPhantom> Either I'm older and wiser… or OCaml is well-written. 😛
<d_bot>
<KW78> Well, you still need to understand how a GCed language works and the underlining C runtime. So you are definelty wiser
mro has quit [Remote host closed the connection]
mro has joined #ocaml
waleee has joined #ocaml
gravicappa has quit [Ping timeout: 240 seconds]
mro has quit [Remote host closed the connection]
omr has joined #ocaml
mro has joined #ocaml
omr has quit [Quit: WeeChat 3.3]
mro has quit [Remote host closed the connection]
mro has joined #ocaml
Haudegen has joined #ocaml
mro has quit [Remote host closed the connection]
zebrag has joined #ocaml
* qwr
has impression, that ocaml implementors tend to merge new things after these are really well thought out
<qwr>
most popular OO languages in comparison are a bit like gobbled together by madmans, and haskell has enourmous amount of research extensions used in practice
jlrnick has joined #ocaml
<qwr>
of course sometimes this has delayed things considerably, like the multicore coming next year
spip has joined #ocaml
Guest9141 has quit [Ping timeout: 240 seconds]
spip is now known as Guest4969
<d_bot>
<VPhantom> Yes I like OCaml's approach there. Slow, deliberate changes and keeping a very close eye on possible performance regressions.
<d_bot>
<VPhantom> I wish the Stdlib did a bit more, but it's already quite nice to work with. (I was a bit too quick to jump to Base/Core when I got started, having learned initially from _Real World OCaml_.)
<d_bot>
<minimario> "%obj_is_int" vs "caml_obj_is_block"
<d_bot>
<octachron> `%` is used for compiler primitives
mro has joined #ocaml
<companion_cube>
@NULL: yeah I had to use it a tiny bit, and I hate that
<d_bot>
<NULL> And François Pottier is also looking for a way to make menhir type-safe and remove the need of Obj, so that amounts to 0 people that are okay with using it
<companion_cube>
probably a good call with the upcoming flambda2
<d_bot>
<NULL> Though for menhir it was mostly discussion because he didn't have much time to spend on it IIRC
<d_bot>
<minimario> why does menhir need obj
<d_bot>
<NULL> Production rules aren't completely typed, with the fact that arguments are constructed in a weird order and you need to store them still
<d_bot>
<NULL> I don't know well enough, but that's what I understand
kaph has quit [Ping timeout: 245 seconds]
<d_bot>
<octachron> The next version of Menhir doesn't use `Obj` anymore (due to a generous use of GADTs to track the type of the stack and a new IR for optimizations).
<companion_cube>
that's really nice
<companion_cube>
is that why type inference is becoming mandatory?
<d_bot>
<NULL> So I remembered wrong, it is already being written. Also, for the uses of `Obj`, there's also Coq code extraction because Coq's type system is stronger than OCaml's
mro has quit [Remote host closed the connection]
<d_bot>
<minimario> stronger in what sense?
bartholin has quit [Quit: Leaving]
<companion_cube>
incredibly more expressive
<d_bot>
<minimario> like dependent types?
<companion_cube>
yep
<d_bot>
<NULL> Those and inductive types and much more
<d_bot>
<minimario> what exactly are inductive types
<d_bot>
<NULL> Intuitively, dependent sum types
<d_bot>
<NULL> More formally, I'm going to learn this in January
<d_bot>
<minimario> have an easy example in mind? 🙂
mbuf has quit [Quit: Leaving]
<d_bot>
<NULL> ```coq
<d_bot>
<NULL> Inductive eq (A : Type) (x : A) : A -> Prop := eq_refl : x = x
<d_bot>
<NULL> ``` Coq's equality type
<d_bot>
<minimario> is this not just a dependent type
<d_bot>
<NULL> You're explicitly giving the constructors (here, eq_refl)
<d_bot>
<minimario> oops i don't read coq syntax
<d_bot>
<minimario> A->Prop is the return type?
<d_bot>
<NULL> (IRC users, are single line code blocks fine or does it print the \`\`\`coq header and all ?)
<d_bot>
<NULL> This is close to OCaml's `type (_, _) eq = Eqrefl: ('a, 'a) eq` but here you define an equality type for values and not just types
Anarchos has quit [Quit: Vision[]: i've been blurred!]
<d_bot>
<NULL> `eq A x y` is a Prop and `eq_refl A x` is an inhabitant of `eq A x x` (yes `A -> Prop` is the return type)
<d_bot>
<Et7f3> the base is 4000 commit behind but in fact it is 240 commits
<d_bot>
<NULL> and `=` is infix for `eq` where the first argument `A` is left for the type checker to be inferred
<d_bot>
<Et7f3> +many merge commit so in fact it is less if we rebase properly
kakadu has quit [Quit: Konversation terminated!]
<d_bot>
<VPhantom> FYI that's a very old fork of OCaml. The active repo is at <https://github.com/ocaml/ocaml>. I refer to it often when I want to know how something is implemented in more detail.
waleee has quit [Quit: WeeChat 3.3]
waleee has joined #ocaml
Haudegen has joined #ocaml
rgrinberg has joined #ocaml
mro has joined #ocaml
<d_bot>
<cemerick> oh, fair enough, I was just impressed with the top-line number
<d_bot>
<cemerick> obligatory 🤦 re: the HN discourse
mro has quit [Ping timeout: 268 seconds]
<d_bot>
<VPhantom> It went sideways? The parts I saw were alright. 🤔
<d_bot>
<cemerick> bulk of it seems to be spats about OCaml's merit vis a vis haskell and F#
<d_bot>
<VPhantom> Oh, yeah.
<d_bot>
<VPhantom> But I think it's natural to try to parallel with what people might be more familiar with (Rust, Go, Haskell, F#, etc.)
<d_bot>
<VPhantom> Personally for the work I do, the merge won't change anything yet. When EIO will come out of development, and when we might get hands-off concurrency like Go's goroutines, that's when I'll take notice and change how I do things. (Or maybe that's already what "domain pools" are under the hood?)
<companion_cube>
that's a point in the discussion: whether domainslib and eio will cooperate well?
<d_bot>
<VPhantom> (By "hands-off" I mean that in Go's goroutines like with Lwt's in-process promises, you create one and let it be scheduled. Go spreads them over several cores as it sees fit, vs right now as I understand it, developers need to decide what runs in which domain.)
<companion_cube>
hmm not necessarily, I think domainslib gives you a thread pool
<companion_cube>
well, a domains pool, and "tasks" on top of it
<d_bot>
<VPhantom> It'll be interesting to see how Lwt will integrate that. From the looks of their issues list they seem to have more work than manpower already. 😕
<companion_cube>
I'm a bit worried about eio personally
<companion_cube>
I'd rather they work on lwt
<d_bot>
<VPhantom> I thought EIO was the prototype for what would eventually be added to Stdlib?
<companion_cube>
as is we're going to have eio, lwt, async, and the standard IOs
<d_bot>
<VPhantom> Oh…
<companion_cube>
I'm not aware of that, and a big library like that is never easy to merge into the stdlib
<companion_cube>
unless there's a RFC I missed
<d_bot>
<VPhantom> I was hoping to maybe be able to "shed" Lwt as a dependency when OCaml "5.1" would arrive.
jlrnick has quit [Remote host closed the connection]
<d_bot>
<VPhantom> No I must've misread the monthly update where I saw that. You're certainly right.
<companion_cube>
but what about all the existing code that provides Lwt interfaces?
<d_bot>
<VPhantom> I mistakenly thought that EIO was part of the Multicore effort and that it was merely scheduled for merging later than what's being merged now.
<d_bot>
<VPhantom> Well, there's also Async code. I think that if the Stdlib came up with something great thanks to Multicore, it would be worth migrating to it over time.
<companion_cube>
it's part of the multicore project, not of the main PR
<companion_cube>
well my hope is that lwt and async could finally agree on a common "future" representation that takes advantage of multicore
<companion_cube>
like a common effect basically
<d_bot>
<VPhantom> Okay so that must be why I thought it was on its way to the Stdlib then. 😉
<companion_cube>
(and each provide their own handler)
<companion_cube>
"my hope" as an outsider, I should say.
<d_bot>
<VPhantom> Given the small size of the community, the more we can agree on and the less we can implement redundantly, the better. (Like, right now there's at least 4 "bigstring" libraries I'm aware of for example.)
<companion_cube>
the bigstring libraries should be compatible, if they all rely on the same bigarray type
<companion_cube>
(it's the case for bigstring and bigstringaf at least)
<d_bot>
<VPhantom> (…while there's no `bytes` support in `ocaml-protoc` and no JSON support in `ocaml-protoc-plugin`. I wish I had more time to contribute all the missing pieces I keep discovering.)
<d_bot>
<VPhantom> True, they are.
jlrnick has joined #ocaml
spip has joined #ocaml
Guest4969 has quit [Ping timeout: 268 seconds]
spip is now known as Guest4376
<rgrinberg>
Lwt isn't going anywhere
<companion_cube>
all i want is `wait : pool -> 'a Lwt.t -> 'a` ;-)
<companion_cube>
(with a domainslib pool)
<companion_cube>
rgrinberg: do you have more details? :D
<rgrinberg>
regarding Lwt?
<companion_cube>
yeah
<companion_cube>
curious to hear what you think will happen
<rgrinberg>
I know as much as you do, I just don't see all that Lwt code being thrown away over night.
<companion_cube>
right, I agree
<d_bot>
<Anurag> similarly i highly doubt async will go anywhere.
<companion_cube>
I'm just worried that eio will fragment further
<companion_cube>
and with dubious architectural choices, too
jlrnick has quit [Remote host closed the connection]
<rgrinberg>
Given that we're OCaml programmers, fragmentation is inevitable :)
<rgrinberg>
More seriously, it seems easy to make Lwt play nice with eio apps
<companion_cube>
realistic, or pessimistic?
<rgrinberg>
at the cost of some overhead of course
<companion_cube>
I think eio should play with lwt
<companion_cube>
not the other way 😠
<Armael>
🤔
<companion_cube>
I can't wait to be the grumpy curmudgeon who sticks with lwt just because I find it less annoying than eio :D
<d_bot>
<Anurag> At the moment the one option I can see myself switching to (instead of lwt at work, and async at home) is dune's fiber 🙂
jlrnick has joined #ocaml
<d_bot>
<Anurag> I also think that the io runtimes not being in the stdlib seems to be working well for Rust as well. They have `tokio` , `async-std` , and a couple other newer options designed for linux and using io_uring. Not sure if the interop story in the rust ecosystem has improved, but each alternative is approaching problems from different sides and they all seem to have their own active set of users.
<companion_cube>
it hurts rust as well imho
<companion_cube>
fragmentation is bad
<companion_cube>
but most people seem to be using tokio afaict?
<companion_cube>
(and at least they have a common future type, that's already better than OCaml :/)
gravicappa has quit [Ping timeout: 240 seconds]
<rgrinberg>
Tbh, we don't need a common future type
<rgrinberg>
we need a way to write code polymorphic over future implementations that isn't functors
<companion_cube>
I fail to see how that can happen without a common type
<rgrinberg>
There will never be agreement on a common future type. I see eio decided to bake in exceptions into its promise like lwt, which means that async will likely need its own thing
<rgrinberg>
a future has a well defined interface, write your code against that interface
<companion_cube>
which requires a functor
<rgrinberg>
hence my caveat "that isn't functors"
<companion_cube>
I'm not sure what you're implying, it seems impossible to me :)
<rgrinberg>
you don't think modular implicits would help the issue?
<companion_cube>
if every single function returning a future needs a `let f {Fut:FUTURE.S} : 'a Fut.t = …` , then probably not
<companion_cube>
(not that I think this will ever happen.)
<companion_cube>
s/ever/in the next 10 years/
<rgrinberg>
Hmm, well I see nothing wrong with that signature :)
<companion_cube>
well it's just a local functor for every single symbol, it's also too heavy
mro has joined #ocaml
<rgrinberg>
if it's heavy syntactically, surely that can be addressed?
<d_bot>
<Anurag> wouldn't you still need some form of consistency in how the various systems prefer to deal with exceptions, errors etc. The part that's always left me a little unsatisfied when abstracting over lwt and async has been the different handling of exceptions in the two systems.
<companion_cube>
let+future f = … ? :D
<rgrinberg>
yes, to write generic code you will always need to think about error handling. I don't see how that can ever be avoided until lwt and async agree
<rgrinberg>
luckily it's not a huge issue in practice
jlrnick has quit [Remote host closed the connection]
Haudegen has quit [Quit: Bin weg.]
jlrnick has joined #ocaml
jlrnick has quit [Remote host closed the connection]
jlrnick has joined #ocaml
<rgrinberg>
companion_cube I think that the "common promise type" you suggested is actually the less practical option
<rgrinberg>
For example, eio's promise is thread safe while lwt's isn't
<companion_cube>
rgrinberg: alternatively, a common effect
<companion_cube>
and various implementations of `'a fut -> 'a` based on this effect :p
<rgrinberg>
companion_cube sure that's good too. if we had typed effects, it would also pollute your type signatures though :)
<companion_cube>
🤷
<companion_cube>
I think we're still fucked, but well
Haudegen has joined #ocaml
<rgrinberg>
i don't know, i'm much more optimistic
<rgrinberg>
my only worry is JS really
<d_bot>
<Anurag> I probably have a naive optimistic view that even the current situation is not as bad as it might look like. Yes there are multiple libraries that are now being written in a way that the core logic is in a IO Independant library that then gets wrapped in lwt/async etc. The same libraries will now also be easy to port to eio, <new io library here> as a result.
<companion_cube>
sure, we can keep doing the functor thing
<d_bot>
<Anurag> I meant more like the approach take by httpaf, jsonm etc (where applicable).
<companion_cube>
I guess, it's a lot of supplementary work though
<rgrinberg>
Hmm, effect continuations don't capture the C stack, right?
<companion_cube>
I'm not sure
<d_bot>
<Anurag> `decompress` is another good example I guess. Its more upfront work for the core library, but in turn you get something that works really well with any kind of IO layer.
<rgrinberg>
Looks like C frames aren't captured. A bit of a shame
jonasbits has quit [Quit: No Ping reply in 180 seconds.]
jonasbits has joined #ocaml
<d_bot>
<antron> markup.ml also works with any i/o library. it's internally written in cps to support that
<d_bot>
<antron> as opposed to a functor
<companion_cube>
@antron you should write on how that's done
<companion_cube>
I imagine it's just a particular monad
<d_bot>
<antron> it's probably a monad but i doesn't explicitly use `bind`
<d_bot>
<antron> (or map)
<companion_cube>
do you use a continuation every time you need to read a char, or a string?
<d_bot>
<antron> it's just a bunch of fairly disciplined and consistent cps with an adapter to synchronous i/o or lwt at the very outer surface
<companion_cube>
(this only parses strings though, easier for backtracking)
Anarchos has joined #ocaml
Anarchos has quit [Ping timeout: 256 seconds]
rgrinberg has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
mro has quit [Quit: Leaving...]
Guest4376 has quit [Quit: Konversation terminated!]
<sadiq>
companion_cube, this is out of my area so I may have misunderstood but I think someone's trying to figure out how to get Lwt and Eio to coexist.
rgrinberg has joined #ocaml
tizoc has quit [Quit: Coyote finally caught me]
<companion_cube>
rgrinberg: also struck me : JS is already broken today
<companion_cube>
CPS won't work well with jsoo
tizoc has joined #ocaml
rgrinberg_ has joined #ocaml
rgrinberg has quit [Ping timeout: 256 seconds]
<companion_cube>
@antron btw the record solution is better because you can return any type, not just unit
rgrinberg_ has quit [Client Quit]
<d_bot>
<rgrinberg> Yes, and one cannot simply capture the stack with existing JS anyway