<diml>
hcarty: it has been fixed in the development version
<rixed>
hcarty: there was a bug like this in some versions of lwt some time ago... like in 2.0 or so.
<hcarty>
diml: Any idea why I would get an (unhandled) EINTR on "readable"? Again, Lwt's prevention of complete backtraces makes this difficult to track down.
<diml>
hcarty: the fact that it is raised outside of lwt is not the problem
<hcarty>
diml: I have something raising Not_found in some code using Lwt. I am passing -lwt-debug to the Lwt syntax extension, but this exception seems to be raised outside of Lwt. Any suggestions on how to track the cause down?
<hcarty>
Zedrikov: Ooops, yes - copy/paste error
<Zedrikov>
hcarty: You do not even need "rec" for that, and do not need either "f" to be a function
<hcarty>
Similar - let rec f x : ttt = raise Exit
<hcarty>
mrvn: I agree
<mrvn>
hcarty: but f x never terminates so that is ok
<hcarty>
Zedrikov: Ah, I see - type ttt let rec f x : ttt = f x
<Zedrikov>
hcarty: That is why I precised that you *shouldn't* rather than *can't*, although there are some cases where Obj.magic can be used (I think of the coq extraction mechanism)
<Zedrikov>
hcarty: I know it. There is also a way to have a symbol of a given type through endless recursion
<hcarty>
Zedrikov: The only way you could create a value of an abstract type without using a function in the same module is by breaking the type system (ex. Obj.magic)
2012-04-18
<thelema_>
maybe hcarty knows how to use the p-printing in batteries to print sets
2012-04-17
<hcarty>
vext01: Not in the same module or you run into trouble
2012-04-16
<hcarty>
thelema: That's why the name was changed - Ireland kept getting all the credit :-)
<thelema>
hcarty: the ocamlpro folks were working on inlining; I'm not sure how far they were able to get
<hcarty>
With some activity recently if I recall correctly
<hcarty>
mrvn: Regarding inlining and polymorphism I think there is a bug report or few about that
<hcarty>
mrvn: Thanks for the GC clarifications.
<mrvn>
hcarty: iirc the GC does it when it gets called.
<hcarty>
mrvn: Doesn't OCaml manage that unless you're calling out to C?
<mrvn>
hcarty: since ever. you need to release the runtime lock for other threads to run.
<hcarty>
mrvn: Since when is it not?
2012-04-15
<hcarty>
Not a good thing perhaps, but a common thing.
<hcarty>
vext01: And 'usually failed on non-linux systems' seems to be a very common issue in programming languages
<vext01>
hcarty: ok i dont know about that
<hcarty>
vext01: I think that's part of what Strawberry Perl is meant to address. I don't know how successful it is.
<hcarty>
There is something of a similar issue in Perl-land to what exists in OCaml-land. The 'right' tools exist, but not everyone uses or knows about them.
<adrien>
hcarty: noted ;-)
<hcarty>
adrien: cpanm... skip cpan entirely :-)
<hcarty>
And you still may need to setup some per-.pl configuration or environment variables to make everything play nicely
<hcarty>
That said, even Perl needs some help - cpanm is miles ahead of the default cpan for easy of use
<hcarty>
thelema_: Perl has a similar issue, but (arguably much) better out of the box defaults
<hcarty>
vext01: You can't always tell which .cma/.cmxa to load based on a module's name
<hcarty>
thelema_: It already exists, at least to some extent, in ocamlscript
<hcarty>
thelema_: Which makes for an ocean of insanity. Hooray for odb!
<thelema_>
hcarty: yes little, incompatible, islands of sanity
<hcarty>
thelema_: But sadly not as much upstream
<hcarty>
thelema_: To be fair, it's been that way for a while in Debian, Fedora, GODI
<hcarty>
vext01: open does something different than #load or #require
<thelema_>
hcarty: yes, although I'm thinking about something a bit more complex - have BatText parent all the unicode code and expose utf8 ropes.
<hcarty>
thelema_: Any chance that ulib can still become BatUlib before 2.0 is released?
2012-04-14
<hcarty>
thelema: ocamlbrew update pushed as well
<hcarty>
Thanks
<hcarty>
thelema: Looks good!
<thelema>
hcarty: pushed, please test
<hcarty>
s/Once/After/
<hcarty>
thelema: Once odb is updated I'll push an update to ocamlbrew
<hcarty>
thelema: Do you have time to make the change? If not I can make it later and submit a pull request.
<hcarty>
thelema: Ok, a few tests later - how does OCAML_BASE sound (or OCAMLBASE)? Something relatively generic that would work for GODI, ocamlbrew, and hand-built OCaml installations.
<hcarty>
thelema: I think so. Let me do a few tests here then confirm one way or the other.
<hcarty>
So the simplest thing to do may be for me to add something like an OCAMLBREW_LOCALBASE definition in ocamlbrew. Then odb could detect that and do the exact same thing it's doing with GODI_LOCALBASE.
<hcarty>
Setting GODI_LOCALBASE to point to the root of the ocamlbrew'd OCaml install does the right thing
<hcarty>
thelema: Which, IIRC, was something you suggested a long time ago :-)
<hcarty>
and use the same bin/ dir as ocaml(c|opt|...)
<hcarty>
I want to change that to the more 'normal' $HOME/ocamlbrew/ocaml-3.12.1/lib/ocaml/site-lib/
<hcarty>
thelema: The current default ocamlbrew configuration has odb install everything to $HOME/ocamlbrew/ocaml-3.12.1/odb/(bin|lib|...)
<thelema>
hcarty: I'm up for making odb work better with ocamlbrew - do you want me to detect one of the ocamlbrew environment variables?
<hcarty>
Without this change, ocamlfind needs to have -destdir provided in order to remove an odb-installed library.
<hcarty>
thelema: This would hopefully make ocamlbrew + odb a bit more seamless
<hcarty>
thelema: As opposed to the current default which tells odb to install to a separate location
<hcarty>
thelema: For odb, I'd like to change the GODI_LOCALBASE detection to something more generic. The current GODI support should work well for ocamlbrew + odb installing to the default site-lib.
<hcarty>
mrvn: Agreed
<mrvn>
hcarty: ok, althout it depends on your arch what error you get on stack overflow.
<hcarty>
mrvn: A stack overflow can cause a segfault without any C calls outside of the core language
<hcarty>
thelema: Yes
<thelema>
hcarty: stack
<hcarty>
Even without unsafe
<hcarty>
mrvn: Yes it can
2012-04-12
<hcarty>
adrien: Given that, I'm not sure why it isn't #1 :-)
<hcarty>
adrien: Ah... of course
<hcarty>
thelema: I'm rather impressed that your github site is the 4th Google search result for odb, and the matching oasis-db site is the 5th.
<pippijn>
hcarty: yes, the moving aspect is my main point why I use let in
<hcarty>
_habnabit: Oops - this is probably my fault. The Homepage field points to Calendar's page :-)
<hcarty>
Hopefully having a consistent upstream name will eventually remove the confusion.
<hcarty>
I think I have a compatibility package around somewhere ... it's a Makefile + META file to install a dummy zip/camlzip package that depends on the other
<hcarty>
The latest Subversion revision uses zip as the ocamlfind install name
<hcarty>
findlib name
<hcarty>
It looks like upstream uses 'zip' as the findlibnap
<hcarty>
_habnabit: Please do, thank you
<hcarty>
It's probably worth submitting upstream
<hcarty>
It looks like your _oasis is a proper oasis-ification of the library
<hcarty>
The one I put together, IIRC, only wraps the existing Makefile
<hcarty>
_habnabit: Your _oasis is much better
<thelema>
hcarty: camlzip vs. ocamlzip
<hcarty>
_habnabit: How did you upload it? I only see the version I uploaded.
<hcarty>
_habnabit: I did too :-)
<_habnabit>
hcarty, I uploaded that, haha
<hcarty>
_habnabit: (caml)zip is already on odb - you can look at the _oasis file there if you want
<hcarty>
_habnabit: Debian has it one way, GODI has it another
<hcarty>
pippijn: using 'in' everywhere 'and' is not needed also makes it easier to move code around.
<hcarty>
mrvn: 'want' implies that the illusion of simultaneous access may be sufficient
<hcarty>
mrvn: 'want' may be key there
<hcarty>
mrvn: But in CS it apparently does not... that has been my take as an english speaking, non-CS-PhD'd observer.
<hcarty>
Anarchos: ^^
<hcarty>
Bug Tracking System
<Anarchos>
hcarty: the BTS ?What is it ?
<hcarty>
They have done a lot of cleanup in the BTS but I'm sure there is a large backlog to get through.
<hcarty>
The core development team seems to have grown significantly over the past year or so.
<hcarty>
mrvn: It's been a few years since your patch was submitted. Perhaps pinging the core team would help.
<hcarty>
Rather than a cold/dry technical discussion and proposal.
<hcarty>
A lot of the concern seemed to revolve around the apparent emotion driving the proposed fork
<hcarty>
My guess is that a proven implementation will go a long way toward to easing the core team's concerns. Particularly if the implementation is shown to be active in tracking the core team's development and working with the core team if/when changes transition from the experimental community branch to the core implementation.
<hcarty>
s/string/strong/
<hcarty>
mrvn: That was my take as well. I'm not pushing for it - OCaml's development works for me in its current form. But if there is a string enough community need/desire for such a project then I think it could be made to work.
<mrvn>
hcarty: read the last discussion on the ML about it. My take was that the core people are against it.
<hcarty>
A community branch with experimental patches has been proposed a few times. If people maintained it actively I imagine such a branch would get community interest and support.
<hcarty>
mrvn: It may be a matter of catching the attention of a core team member who is interested in the feature and willing to support it.
<mrvn>
hcarty: The int31 patch just needs to be commited. I really don't get why that is so hard.
<hcarty>
mrvn: Both useful. Type fiddling may spark more interest.
<mrvn>
hcarty: or O_CLOEXEC
<mrvn>
hcarty: I'm still waiting for my int31 patch for Bigarray to be added
<hcarty>
From github that is
<hcarty>
mfp: The namespaces branch is gone too
<hcarty>
mrvn: Submit a feature request? There may be some willingness to add support if a large enough group expresses interest.
<hcarty>
mfp: The last thing I heard was that it is on hold until other projects are completed.
2012-04-11
<hcarty>
mononofu: If you have any OCaml/PLplot usage questions or suggestions for improvements please let me know. I don't have a lot of time for it these days, but I'll do what I can.
2012-04-10
<hcarty>
adrien: That's a nice warning to receive
<alpounet>
hcarty, uh? what shift in focus?
<thelema_>
hcarty: true
<hcarty>
Or not for much longer
<hcarty>
thelema_: I agree, although with gildor's shift in focus it may not be an issue any longer.
<hcarty>
eni: Most of the available information is there on that site. Batteries is a similar community-driven project.
<hcarty>
Ah, library - sorry for the noise
<hcarty>
eni: Do you mean the library or the company/website(s)?
2012-04-09
<hcarty>
I think the warning is disabled by default in 3.12.x but may be enabled by default in later versions.
<hcarty>
Pre-3.12: let { x; y } = it_has_xyz (* May trigger a warning in 3.12+ *)
<hcarty>
let { x; y; _ } = it_has_xyz
<hcarty>
xlq: Yes. If you are using 3.12.0 or later you can be explicit about it.
<hcarty>
Qrntz: You're welcome. If you ask again, please share the response :-)
<Qrntz>
hcarty, thank you
<hcarty>
Qrntz: This was a year or two ago.
<hcarty>
Qrntz: I've emailed the authors with the same question in the past. They were honest and quick with their answer (at the time - it will lag official releases somewhat, but at the time there was no plan to stop development)
2012-04-06
<hcarty>
diml: I'll try to get something minimal together. This one has been more difficult to reproduce effectively.
<diml>
hcarty: i have no idea, could you give me an example ?
<hcarty>
diml: zeromq throws errors about invalid sockets when a socket was created within Lwt_main.run
<diml>
hcarty: what do you mean they don't work properly ?
<hcarty>
diml: Do you have any idea why this may be true?
<hcarty>
diml: I'm not sure why this is the case, but if I create zeromq sockets within Lwt_main.run they don't work properly. However, if Lwt_main.run is called within the context of existing zeromq sockets then everything works properly.
<hcarty>
diml: Is it harmful to enable the debug flag and OCaml's own backtraces when using Lwt?
<diml>
hcarty: you have to create a myocamlbuild.ml
<hcarty>
diml: Is it possible to enable Lwt backtraces when using ocamlbuild?
<hcarty>
Or ocamlbuild lib.cma lib.cmxa
<ezyang>
hcarty: Hm, that'll be too invasive :-(
<hcarty>
ezyang: Pull the functions, types, etc. you want to put in a library into their own modules. Then get those modules to compile on their own.
<hcarty>
diml: Oh, I see. Even better.
<diml>
hcarty: note that it is not a workaround, when you know that the fd support non-blocking, it is faster to tell it to lwt_unix
<hcarty>
diml: Thank you for the work-around. I tested it and it works here.
<diml>
hcarty: it will be fixed in 5 minutes
<hcarty>
diml: Or has it already been fixed? :-)
<hcarty>
diml: Thank you, I'll give it a shot. Should I report this somewhere?
<hcarty>
xlq: Oops, I misread your message...
<hcarty>
xlq: If you want the constructors too you either need to include the full type definition
<diml>
hcarty: it is a bug in Lwt_unix (a try instead of a try_lwt). Add ~blocking:false to of_unix_file_descr and it will work
<hcarty>
'./foo.native' runs without using Lwt; './foo.native lwt' runs using Lwt
<hcarty>
Built with 'ocamlbuild -use-ocamlfind foo.native'
<hcarty>
xlq: Something along those lines. I've only used ocamllex a bit, but I remember needing to rather liberally store token positions.
2012-04-05
<hcarty>
diml: Of course, that makes sense. Thank you!
<diml>
hcarty: you can always catch Lwt.Canceled and kill the process
<hcarty>
diml: Is the proper work-around for that "don't use Lwt.cancel"?
<hcarty>
diml: Ok. As a simple test I tried to run "sleep 50" in a thread, canceled the thread and quit the toplevel. The sleep process continued to run.
<diml>
hcarty: there is nothing special, if the function passed to with_process_* fails, the process is "closed" (= opened pipes are closed)
<hcarty>
diml: Lwt_process.(with_process_full, exec) for example
<diml>
hcarty: you mean for pread*, pwrite* and pmap* ?
<hcarty>
diml: Is the effect of Lwt.cancel defined for processes spawned with the Lwt_process module?
2012-04-04
<hcarty>
Batteries likely has something more readily available, perhaps in the IO module
<hcarty>
_habnabit: Yes, I think the Unix module does that internally in a few places
<hcarty>
_habnabit: Unix.pipe?
<hcarty>
ben_m: Gtk2 + Cairo may be your best bet under OCaml if you want interactivity. If you want something simpler and easier to get started with, the Graphics module that comes with OCaml may be useful.
2012-04-03
<pippijn>
hcarty: yes, but not today
<hcarty>
pippijn: Can you test Batteries git against js_of_ocaml? If it doesn't work then that would be a good thing to know before release.
<hcarty>
A lack of Camomile dependence in Batteriex 2 will be very welcome :-)
<hcarty>
pippijn: All (most?) of Batteries 1.x does, due to the IO support
<hcarty>
No
<hcarty>
Comprehensive libraries are up to the community to develop - which is a large part of why Batteries came to exist.
<hcarty>
pippijn: The compiler
<pippijn>
hcarty: what's their focus?
<hcarty>
pippijn: Also, stdlib doesn't have an Option module. And it probably shouldn't, given the core team's focus.
<hcarty>
pippijn: But that propagates everywhere downstream
<hcarty>
pippijn: 'exceptional' is subjective
<pippijn>
hcarty: Option.map/Option.may
<hcarty>
pippijn: But 'a option makes the arguably usual case (find found something) more difficult to handle.
<hcarty>
I think Core does the same thing out of the box, at the cost of any stdlib compatibility layer.
<hcarty>
pippijn: If you use Batteries then you can have lots of find-and-friends return 'a option types instead of raising exceptions.
<hcarty>
pippijn: Thank you. That's what I expected/hoped.
<hcarty>
Or... I may be thinking about this in an un-Lwt-ish way. I could pass the mvar-checking thread along until it returns a value.
<hcarty>
diml: So without a Lwt_mvar.is_full or similar function I can't use an mvar and avoid blocking.
<hcarty>
diml: Is it safe to use a ref for communication between threads? I have a few points where a checkable mvar would work, but the check fits most logically inline with other processing.
<hcarty>
diml: I think that will work well. Thank you for taking the time to answer my questions.
<diml>
hcarty: yes
<hcarty>
diml: And wrap each thread in a variant? type result_t = Thread of thread_result_t | Task of task_result_t
<diml>
hcarty: maybe you can just put the Lwt_mvar.take in the choose too
<hcarty>
The number of threads (tasks) is not constant.
<hcarty>
diml: I'm trying to figure that part out too :-) I am planning to use nchoose_split so that I can separate the completed threads from the ongoing threads.
<diml>
hcarty: how do you monitor your threads ? with Lwt.choose ?
<hcarty>
s/tasks/task threads/
<hcarty>
The other thread has its own list of task threads which it monitors. I need this thread to be able to check for a value in the mvar and continue to monitor the existing list of tasks.
<hcarty>
I have one thread which is listening on a zeromq socket for tasks to perform. When a task arrives it is put in an mvar to be picked up by another thread.
<hcarty>
diml: Lwt.state may allow me to do what I need.
<diml>
hcarty: no, the exported functions does not allow that
<hcarty>
diml: Or do I need to use Lwt_stream or some other inter-thread communication technique in order to avoid blocking?
<hcarty>
diml: Is it possible to check the state of a Lwt_mvar.t (empty/full) without blocking?
2012-04-02
<hcarty>
_habnabit: Yes, OCaml's bug tracker
<hcarty>
_habnabit: There was some discussion on the bug tracker about this. I don't remember the bug # or if there was a work-around.
<hcarty>
I'll leave it as a paste for now, but if I develop it any further or if anyone else wants to make any additions I will setup a proper project for it.
<hcarty>
diml and others: Thank you for your help.
<diml>
hcarty: looks fine to me
<hcarty>
It compiles and the types work out, but I'm still new to the world of Lwt.
<hcarty>
ZMQ.Socket.events itself should not block according to the documentation
<hcarty>
smondet: Thanks. As I understand, ZMQ.Socket.events tells you if a complete ZMQ message can be read/written on the given socket without blocking.
<smondet>
hcarty: I don't know exactly what ZMQ.Socket.events does, but if it tries to read more than one byte with non-Lwt Unix.recv, then I guess Lwt_unix.wait_read is not enough
<hcarty>
avsm: Thank you for the Lwt-for-managing-processes-and-other-Unix-things tip. It's been fun learning the library.
<hcarty>
If anyone familiar with integrating Lwt with other libraries is available, I would appreciate comments on a small Lwt/0MQ interface : https://gist.github.com/2279558
2012-03-31
<hcarty>
gildor: Thanks for the update. I'll hold off on trying to push anything to oasis-db using a newer oasis until then.
<gildor>
hcarty: oasis-db will support 0.3 a week or two after the release of 0.3