Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Jan 27 12:47
    Et7f3 commented #919
  • Jan 27 12:46
    Et7f3 commented #919
  • Jan 26 18:19
    smorimoto converted_to_draft #913
  • Jan 26 18:18

    smorimoto on improve-documentation-lwt-unix

    (compare)

  • Jan 26 18:18

    smorimoto on master

    Lwt_unix: improve documentation Merge pull request #922 from oc… (compare)

  • Jan 26 18:18
    smorimoto closed #922
  • Jan 26 18:18
    smorimoto closed #920
  • Jan 25 13:46
    dinosaure commented #924
  • Jan 25 13:21
    raphael-proust opened #924
  • Jan 24 10:30
    MisterDA commented #918
  • Jan 24 10:22
    MisterDA synchronize #918
  • Jan 23 23:12
    patricoferris edited #923
  • Jan 23 23:03
    patricoferris opened #923
  • Jan 23 05:49
    smorimoto labeled #922
  • Jan 22 20:05
    madroach commented #917
  • Jan 21 12:25
    MisterDA commented #918
  • Jan 21 11:33

    raphael-proust on master

    Lwt.pick and Lwt.choose pick pr… Use `Result.{Ok,Error}` for com… Mention pick/choose fix in CHAN… and 1 more (compare)

  • Jan 21 11:33
    raphael-proust closed #874
  • Jan 21 11:33
    raphael-proust closed #856
  • Jan 21 11:20
    raphael-proust commented #918
Tóth Róbert
@StrykerKKD
@aantron Guess I will try to make the second option work, because the first option isn't really space efficient. Thanks for the answer.
Avni Fatehpuria
@AvniFatehpuria
I just made my first PR, and I'm wondering if anyone can give me advice on what issue to work on next? I'm fairly familiar with OCaml, but new to open-source + large codebases in genera
Anton Bachin
@aantron
@AvniFatehpuria thanks, i'm currently reviewing the PR. it's tricky code :)
I think Lwt is out of truly easy issues. you may want to browse around other projects that you use/know of
you could of course try something more complicated in Lwt, or try publishing some code of your own :)
Avni Fatehpuria
@AvniFatehpuria
I would be happy to try something more complicated
Is there something in particular I should look at?
Thank you for all your help!
Didier Le Botlan
@lebotlan
Hi Lwt lobby (is someone still there ? last message seems one year ago).
matrixbot
@matrixbot
slekaml Salut Didier!
slekaml Oh sorry I mistook this chan for the chan of the people who took the ocaml mooc
Didier Le Botlan
@lebotlan

@matrixbot slekaml (Salut ! Et qui est slekaml ?)

Anyway, I have run into a curious pb :

let open Lwt_io in
let () = Printf.printf "FLUSH-1.1b\n%!" in          
flush stderr ;%lwt
let () = Printf.printf "FLUSH-1.1c\n%!" in
[etc.]
The above code blocks at flush (FLUSH-1.1b is printed, but not FLUSH-1.1c)
BUT, this occurs in a very big program, involving ocsigenserver, eliom, various libraries of mine. Of course, I am unable to reproduce it in a small example.
Question : how can possibly flush stderr block ?
Hint : it really blocks the process. CTRL+C has no effect on the running process.
Didier Le Botlan
@lebotlan

Other hint : I have a periodic (debug) task which prints dots :

 let rec loop () =
    Lwt_io.printf "." ;%lwt
    Lwt_unix.sleep 0.1 ;%lwt
    loop ()

As the FLUSH blocks, this loop may block or not (same executable launched a couple of times : once it prints dots repeatedly, but FLUSH is blocked, once it does not print dots and FLUSH is also blocked).

Finally, I am using lwt.4.3.0 (opam pin --dev-repo), ocaml 4.08.1
Anton Bachin
@aantron
@lebotlan I'm not sure why it would hang like that. Looking at the code, it seems like Lwt_bytes.write would have to hang, emptying the internal Lwt_io channel buffer. I suggest to either narrow the case as much as you can, by deleting huge chunks of code from a second copy of your project, or to put lwt as a sibling project of yours into a dune workspace and instrument Lwt_io with prints to get a better idea of what is going on
as for gitter, it still sends me notifications :) though issues is easier, because the notifications are immediate, whereas gitter delays them. i may disable gitter because of that
Didier Le Botlan
@lebotlan

@aantron Thank you for your reply (I wasn't sure this deserved an issue :) )
I'll follow your advice (and also try some other hacks that came to my mind).

For the moment, the bug has disappeared (also I am pretty sure I have not recompiled, only changed the environment - IP, dual screen). So it seems non-deterministic.

My guess is that it is some sort of race-condition, which might be difficult to reproduce in a small program. Anyway, I'll see what I can do.
Anton Bachin
@aantron
+1
also check this issue, which has just been solved in master: ocsigen/lwt#704. it affected Lwt programs that called fork, on glibc > 2.24 (not sure exactly which version of glibc introduced the problem). if you used opam pin --dev-repo, you are likely not using exactly lwt 4.3.0. to be sure about which commit you are using, do a normal git clone, check git log, and then do opam pin add lwt .
Didier Le Botlan
@lebotlan
Thanks, I'll have a look. First I need to get my unsolved bug back :)