<discocaml>
<gooby_diatonic> Tbf, the OCaml community is such that I'm surprised with what we have online already
<discocaml>
<gooby_diatonic> Most people already have their local setups and don't need online playgrounds
<discocaml>
<contificate> yeah, soon the online playground will be integrated into the French DuoLingo course
wbooze has joined #ocaml
Haudegen has quit [Quit: Bin weg.]
<discocaml>
<mimi_baboon> fair
<discocaml>
<contificate> made an issue for the `/` behaviour, should be an easy fix
alfiee has joined #ocaml
alfiee has quit [Ping timeout: 260 seconds]
Haudegen has joined #ocaml
<discocaml>
<romain.beauxis> I do have a coredump usable with gdb, yes. I can inspect the stack and memory. Do you have any suggestions of what I could check. The most important part of the stack is the one I posted above.
alfiee has joined #ocaml
<discocaml>
<cartractor> has anyone in here tried Dream?
alfiee has quit [Ping timeout: 260 seconds]
<discocaml>
<sim642> The stack trace might be misleading though: the corruption of the `bf_large_tree` thing might've happened earlier. I just wonder if the address of the `bf_large_tree` (or whereever that `0xfff...` was read from) comes after some memory that the C stub might have manipulated and accidentally written out of bounds.
<discocaml>
<sim642> Assuming the allocator itself isn't buggy, that's the only thing I can think of that might lead to this.
<discocaml>
<sim642> I don't know where all of that freelist stuff is allocated though. If it's just `malloc`ed (as opposed to some OCaml heap thing), then those blocks might be in between other stuff that the C stub has `malloc`ed
<discocaml>
<boechat107> I have been using it for almost two months. Are you looking for something specific in there?
<discocaml>
<sim642> Also, maybe running under ASan reveals something? I haven't tried it for OCaml but I guess you'd need `ocaml-option-address-sanitizer` to have the runtime built with ASan
<discocaml>
<cartractor> I've never used it - just wanted to know your thoughts on it so far and how it is using it to build a website?
<discocaml>
<boechat107> It covered all the basics for me, including session management. The app I'm building is pretty simple, and I didn't feel like Dream missed something essential yet.
<discocaml>
<boechat107> The lack of activity in the repository in the last months worries me a little, though.
kurfen_ has quit [Ping timeout: 252 seconds]
<discocaml>
<romain.beauxis> Thank @sim642 I'll see what my options are. Last time I tried building with ASan it was a pretty complex considering the boatload of bindings this app has (I initially contribute the opam support for this!).
<discocaml>
<romain.beauxis> But the app only uses two C bindings out of the many it has for that one configuration. I think I'm gonna start by reviewing those. I believe for the most part it's custom blocks with custom finalizers and free calls. I'm pretty surprized by the `0xfff...` value. It seems a little too convenient, I would expect something random.
<discocaml>
<contificate> Convenient but in line with lots of C stuff, as it could have came from `-1`
<discocaml>
<contificate> don't suppose you have a way to stress/aggravate the area of the code you think it's breaking in - might lead to a reliable repro
myrkraverk has quit [Read error: Connection reset by peer]
wbooze has quit [Read error: Connection reset by peer]
wbooze has joined #ocaml
wbooze has quit [Max SendQ exceeded]
wbooze has joined #ocaml
wbooze has quit [Max SendQ exceeded]
wbooze has joined #ocaml
wbooze has quit [Max SendQ exceeded]
wbooze has joined #ocaml
myrkraverk has joined #ocaml
alfiee has joined #ocaml
alfiee has quit [Ping timeout: 252 seconds]
<discocaml>
<romain.beauxis> Woo `-1` very interesting
<discocaml>
<romain.beauxis> I have a reliable repro with the client, it segfaults at least once a day. I'm just not sure what kind of tooling I can put around it. `rr` will not work b/c it is a cloud machine.
<discocaml>
<contificate> could probably look into the core dump in gdb
<discocaml>
<contificate> if I was seeing this, I'd be tempted to actually just create a switch from a dev branch of the compiler and modify freelist.c to give me useful information - it's non-obvious from the flow of calls where that comes from
<discocaml>
<romain.beauxis> great idea, I am actually giving them custom builds already.
<discocaml>
<romain.beauxis> I just can't really find where the value was changed from that file. I think that it's stored there but changed outside of it.
<discocaml>
<romain.beauxis> I wonder if the compiler could allow to add debugging info to the value like a symbol of where it was allocated.
<discocaml>
<romain.beauxis> Looks like it, gonna try that
<discocaml>
<gooby_diatonic> It's pretty nice but only covers strictly the web stuff, so e.g. database interfacing would be delegated to an external library
<discocaml>
<gooby_diatonic> Also it takes some thought to decide how to handle markup since there are multiple approaches
wbooze has quit [Quit: Leaving]
<discocaml>
<cartractor> So if I just wanted to make a portfolio with it, should be perfect? 😮
<discocaml>
<gooby_diatonic> Parfait
<discocaml>
<yawaramin> kinda...but Dream is already integrated with Caqti
<discocaml>
<gooby_diatonic> Yeah though it doesn't feel as "one package" as some other frameworks like let's say Laravel to me
alfiee has joined #ocaml
wbooze has joined #ocaml
wbooze is now known as Inline
Inline is now known as wbooze
alfiee has quit [Ping timeout: 252 seconds]
<discocaml>
<dubious245> :Lore_pout: time to hunt bugs. Oh joy.
Haudegen has quit [Quit: Bin weg.]
alfiee has joined #ocaml
alfiee has quit [Ping timeout: 260 seconds]
chiselfu1e is now known as chiselfuse
alfiee has joined #ocaml
alfiee has quit [Ping timeout: 244 seconds]
dhil has quit [Ping timeout: 265 seconds]
<discocaml>
<regularspatula> Doesn’t ocaml.org run on Dream?
wbooze has quit [Ping timeout: 252 seconds]
<discocaml>
<gabyfle> Yow, just upgraded to ocaml-lsp 1.21 and it looks like my VSCode install can't detect the new version... it keeps saying "consider upgrading to 1.21". I checked the version using ocamllsp --version and it ouputs correctly 1.21.0. Anyone knows where could it come from ? I'm also using the latest OCaml Platform plugin for VSCode.
<discocaml>
<._null._> In VSCode's Output tab, for OCaml commands, can you see `ocamllsp --version` ? Does it also show 1.21.0 ?
<discocaml>
<gabyfle> Yow, just upgraded to ocaml-lsp 1.21 and it looks like my VSCode install can't detect the new version... it keeps saying "consider upgrading to 1.21". I checked the version using ocamllsp --version and it ouputs correctly 1.21.0. Anyone knows where could it come from ? I'm also using the latest OCaml Platform plugin for VSCode.
<discocaml>
<gabyfle>
<discocaml>
<gabyfle> The bug is kinda ennoying because it seems like ocamllsp cannot find the compiled modules anymore, leading to a lot of "undefined module" / functions with red squiggles even tho dune seems to find them
<discocaml>
<gabyfle> I don't see anything related to the OCaml commands inside the output tab
<discocaml>
<dubious245> Bring up the terminal.
<discocaml>
<gabyfle> arf
<discocaml>
<gabyfle> my bad
<discocaml>
<gabyfle> I see haha
<discocaml>
<._null._> There should be, as soon as you have the OCaml extension
<discocaml>
<gabyfle> sorry, didn't knew there was these tabs there
<discocaml>
<gabyfle> hoooo
<discocaml>
<gabyfle> I'm on the ocaml5.2.0-flambda switch
<discocaml>
<._null._> It's mostly for debugging, the issue is the switch you're on
<discocaml>
<gabyfle> Ok I see, the ocamllsp from the OCaml Platform runs on the 5.2.0 switch but I did the upgrade on the 5.2.0-flambda one 🙂 thanks for helping
<discocaml>
<gabyfle> Can I tell OCaml LSP to use my current switch ?
<discocaml>
<._null._> You can't separate the switch where the LSP is run from the switch where the compiler is run
<discocaml>
<gabyfle> Ok that's weird because when I do opam switch, i'm really on the 5.2.0-flambda but the lsp still runs onto an other switch ?
<discocaml>
<._null._> You can however set it so that the switch a project is on is not the global switch
<discocaml>
<._null._> So that might be the issue
<discocaml>
<gabyfle> Is it with the sandbox argument ?
<discocaml>
<._null._> Yes ?
bartholin has joined #ocaml
<discocaml>
<gabyfle> Oh, alright, it worked, this little thing was set to the 5.2.0 by mistake. Again, thanks for helping :p
<cedb>
say im chaining lwt callbacks and one of them is just for sideffects with like ">>= fun p -> (*raise if bad else just Lwt.return()*)" is it good style to do ">>= fun p -> (*if ok Lwt.return*) >>= fun () -> etc" ?