<hcarty>
There is no way to remove/rename module types currently.
<hcarty>
thelema_: 'module type S = ... does not match module type S = ...'
<hcarty>
thelema_: I had submitted a feature request related to this... I think it has something to do with the module signatures in those modules.
<hcarty>
You can have it work that way, but it will take a fair amount of editing or a bit of targeted editing and lots of automted interface generation.
<hcarty>
thelema_: That will require changing interfaces
<hcarty>
thelema_: I agree
<hcarty>
I suppose they could in a future version if a dead code elimination pass is added.
<hcarty>
I doubt they do, at least in the current compiler.
<hcarty>
And the dummy assert can be hidden by an interface
<hcarty>
Yep
<hcarty>
You could use with module A := A to remove that module...
<hcarty>
thelema_: Ah, true. Or module definitions.
<thelema_>
hcarty: if we have the include, I don't think we could include type definitions again
<hcarty>
thelema_: True. You would have to either force a link to the included definition or have the include but still include the definitions inline.
<hcarty>
thelema_: Similar to what Jane St. does for Core IIRC
<hcarty>
thelema_: If you have an interface definition then "include module type of Bar" there should work
<thelema_>
hcarty: yes, I was thinking about doing that.
<hcarty>
thelema_: In real OCaml syntax, preferably...
<hcarty>
thelema_: An ugly solution would be to define Foo_throwaway : module type of Bar
<flux>
hcarty, yeah, asking the right questions is sometimes important :)
<hcarty>
flux: And hooray to you for causing that change :-)
<hcarty>
thelema_: Hooray
<hcarty>
flux: Yes, as long as Float.( + ) is defined as ( +. ) then there should be no performance loss
<hcarty>
rly: It's a pretty straightforward process, but there are a few areas where the build system can get mixed up, such as Tcl/Tk detection.
<hcarty>
rly: I haven't built OCaml svn in a week or two, but I have a few dozen times before that
2012-05-11
<hcarty>
adrien: Fair point
<adrien>
hcarty: well, replacing "while true" with like "while !cond" could be nice too
<hcarty>
thelema: Ok. I'll see what they come back with on the bug report and go from there. I'll find time to come up with a first pass at a minimal file.
<hcarty>
adrien: while true do ... or let rec loop f x = f x; loop f x
<hcarty>
adrien: In this case the only way it's returning is if something raises an exception :-)
<hcarty>
thelema, Ptival: Thanks
<thelema>
hcarty: I'm fine with a minimal packages file
<thelema>
hcarty: 'a, as exit
<hcarty>
If a function never returns (for example, looping forever) it is better to leave its return type as 'a or force unit in the interface?
<hcarty>
thelema: What do you think of a minimal or possibly comments-only packages file for odb installed by default with ocamlbrew, showing users how to add their own custom/non-oasis-db'd packages?
<hcarty>
mrvn: And in Batteries 2.x the main logging module has a functor which may give you the customization you want.
<hcarty>
mrvn: There are a few logging modules that have camlp4 support. I think Lwt's logging module supports this (and requires that you use Lwt). Bolt does as well - http://forge.ocamlcore.org/projects/bolt/
2012-05-10
<mrvn>
hcarty: That won't completly optimize away if I want to turn debugs off.
<hcarty>
mrvn: I'm heading off for a while, but if you have any questions about the module I can answer them when I get back.
<hcarty>
thelema: Ulib has a Matrix/2D-array module which could be pulled from.
<hcarty>
thelema: I have a transpose that could be added to BatArray... but I expect a BatMatrix (or BatArray2d?) would be a better target for something like that.
<jarray52>
hcarty: after running #require "batteries";; the command open ExtLib is not recognized. I'm trying to use the command ExtLib.List.unique.
<thelema>
hcarty: that said, I think its authors consider it like TeX - Perfect because any bugs are intended.
<thelema>
hcarty: actually, extlib is being maintained, although just barely
<jarray52>
hcarty: thanks. #require "batteries";; did the trick.
<hcarty>
jarray52: That said, it's probably better to use Batteries than extlib - as far as I know, extlib is not being actively maintained.
<hcarty>
jarray52: #require "extlib";; I think
<hcarty>
Does anyone here use cmdliner? I'm getting some weird formatting from some of its output.
<hcarty>
jarray52: You're welcome. The ocamlpro folks (and ocsigen folks) did a nice job with it.
<jarray52>
hcarty: I want to thank you for suggesting http://try.ocamlpro.com/ yesterday. That was a great tutorial.
<rixed>
hcarty: I stand corrected. I never know what's belonging to findlib in the repl.
<hcarty>
#list shows findlib package names rather than module names
<hcarty>
rixed: That's not batteries, it's findlib
<hcarty>
mrvn: Unless you stick with TCP and don't allow the display to update until an update has been sent
<hcarty>
mrvn: If you server's interpretation is considered 'truth' then there will be visual differences any time lag or syncronization issues come up
<hcarty>
mrvn: The goto should be enough if you trust the client and/or validate all requests from the client on the server.
<hcarty>
incr thelema
<hcarty>
Very nice
<hcarty>
thelema: Right, so you have fixed versions through packages. That avoids the potential issue of a package on oasis-db being updated to an incompatible version.
<hcarty>
thelema: Even better.
<thelema>
hcarty: actually, this was the simplest way I could figure to have an automated oasis install by a single command, with a guaranteed stable dependency chain
<hcarty>
Oh - is this the ripping off good ideas from barbra thing? :-)
<hcarty>
thelema: Sounds really nice
<hcarty>
thelema: I saw that patches were applied that implied a feature like that, but I don't think we've discussed it
<thelema>
hcarty: true, I (or someone) should really upload these packages that work to oasis-db
<hcarty>
That's not something I want to provide out of the box
<hcarty>
I'm a little reluctant to do that though, since not being on oasis-db implies (perhaps incorrectly) a less cleanly integrated package.
<hcarty>
thelema: If this is not the case then I can update ocamlbrew to stick the packages file wherever it should go
<hcarty>
thelema: And more importantly that it is intended for customization, not as something included by default.
<hcarty>
thelema: I can install the packages file, but it was my impression that packages was an optional thing
<jarray52>
hcarty: Thanks. Now, I understand what jonafan was trying to tell me.
<hcarty>
jarray52: If you just want to get started with language basics then try.ocamlpro.com is a good start, or using rlwrap + the ocaml binary that comes from your distribution
<jarray52>
hcarty: I'm just trying to learn the basics of the language.
<jarray52>
hcarty: Is utop the only other interpreter for ocaml?
<hcarty>
jarray52: You can use odb.ml to ease the build process, but that may be getting ahead of what you want to do at this point.
<hcarty>
jarray52: I'm not sure if it's available anywhere other than compiling from source.
<jarray52>
hcarty: It doesn't seem to be in my distro's repository
<hcarty>
jarray52: But it has been extended/modified to support more features and a friendlier out-of-the-box environment.
<hcarty>
jarray52: utop is still using the same underlying code as the official 'ocaml' binary
<jarray52>
hcarty: Are there other ocaml interpreters?
<hcarty>
jarray52: utop is a customized toplevel with context-sensitive completion, editing support, and a few other goodies.
<hcarty>
jarray52: It can take a bit more effort to get going, but utop is nice as well
<hcarty>
joelr: You're welcome, glad you got it working
<joelr>
thelema, hcarty: the problem was with my use of the packed library outside of the library. i was using modules (callbacks) that were packed but not "exported"
<ssbr_>
hcarty: hahaha
<hcarty>
When read out loud, the type is generally pronounced "ooo, spooky"
<hcarty>
The 'raw' type indicates things like the return value of the call, where output goes, and maybe a few other items.
<hcarty>
ssbr_: The magic happens at compile time. The format string is parsed and the appropriate types fall out of that.
<diml>
hcarty: the difference is only the allocation of: { state = Return () }
<hcarty>
joelr: You're welcome, and good luck
<hcarty>
joelr: Deriving may provide something like that. You would need to use something camlp4-based.
<hcarty>
diml: Is that implementation any better/worse than this? let once d f = Lwt_unix.sleep d >> f ()
<diml>
hcarty: it is the cost of Unix.gettimeofday
<hcarty>
diml: 'cost' as in any kind of overhead
<hcarty>
diml: Do Lwt_unix.sleep threads cost any more/less than a any other Lwt thread?
<hcarty>
diml: Thank you. I wasn't sure if there was something special required beyond sleeping.
<diml>
hcarty: equivalent of Unixqueue.once: let once d f = Lwt.on_success (Lwt_unix.sleep d) f
<hcarty>
thelema: The anti-Java layout.
<hcarty>
joelr: Either approach should work - if you have trouble with packing, it's relatively easy to switch to the approach thelema suggested. Both have their benefits.
<joelr>
thelema: hcarty's solution is a tad more elegant
<joelr>
hcarty: that solves my problem, i think
<hcarty>
joelr: Yes
<joelr>
hcarty: so when i pack into RAPI I can still have an mli file? cool!
<hcarty>
joelr: Pack and use RAPI.mli to hide whatever you don't want users to see.
<joelr>
hcarty: i want a packaged API and then API.MarketData.Flags but no API.Flags
<hcarty>
thelema: I haven't tried it so I don't know exactly how it works
<joelr>
hcarty: i will include the submodule in the parent but how do i hide the submodule then? so that it's not accessible other than via the parent?
<hcarty>
thelema: I saw a bug report that indicated it was supported in 3.11.x, broke in 3.12.x, and is fixed again for 4.x
<thelema>
hcarty: can a pack be packed again?
<hcarty>
joelr: Include or pack each sub-module into its parent
<hcarty>
adrien: Yep. I have a few libraries written that way. There is a parent.mli but no parent.ml
<hcarty>
If you don't pack then the module A, B, C are all directly exposed
<joelr>
hcarty: because your submodules are now under the Parent namespace?
<hcarty>
One somewhat significant one is that packing helps reduce name conflicts
<joelr>
hcarty: i suppose so
<hcarty>
joelr: The advantage of packing A, B, C into Parent rather including A, B, C in Parent?
<joelr>
hcarty: what's the advantage of the approach, though? i want to hide a bunch of modules
<joelr>
hcarty: ^
<hcarty>
thelema: Regarding printing and Ord - yes, it would be very nice to have LefiFi's extension in place for those.
<joelr>
hcarty: is that described somewhere, are there examples?
<hcarty>
joelr: Then it should work, although I haven't tried it
<joelr>
hcarty: does it make it easier?
<joelr>
hcarty: i have 0.3.x
<hcarty>
joelr: With 0.2.x, only if you patch support in yourself
<thelema>
hcarty: yes, ocaml definitely needs a not-flat namespace of modules
<hcarty>
joelr: With 0.3.x, yes
<joelr>
hcarty: can you pack modules with oasis?
<hcarty>
thelema: I'm not a huge fan of it either. I would love to see namespace support added to OCaml.
<thelema>
hcarty: I've had more than my fair share of problems with packing and consider it a dirty hack.
<hcarty>
joelr: You can pack modules to make that work
<thelema>
hcarty: same with ord
<thelema>
hcarty: yes, I'm wishing I could build batteries' print infrastructure on top of that.
<hcarty>
I hadn't read that Lexifi proposal in a while. It looks quite interesting after reading through it again.
<hcarty>
True, similar to how atd works
<hcarty>
But that's a lot of hand-coded (de)serialization to write if they are removing camlp4
<hcarty>
When I looked at it last, sexplib seemed easy enough to use by hand. No more or less difficult than json-wheel.
<hcarty>
thelema: Pervasive serialization support is nice, but something like json would be more pragmatic I would think.
<thelema>
hcarty: ah. |> is better.
<hcarty>
thelema: And it seems (seemed?) to break often, probably due to the camlp4 complexities involved.
<hcarty>
thelema: sexplib is something of a draw, but ultimately not enough.
<hcarty>
IIRC |! is Core's |>
<hcarty>
Also, on a more or less meaningless level, |! is ugly.
<thelema>
hcarty: but sexplib!
<hcarty>
thelema: Bah! :-) I've been tempted by the call of Core. But I can't give up the sweet sweet call of BatIO, BatPrintf, and others.
<thelema>
hcarty: he clearly wants core, because... jane street, I guess. :)
<hcarty>
I've heard rumors that Batteries is a simple "odb.ml batteries" away
<hcarty>
joelr: If it doesn't there, then I may be thinking of one of the other OCaml/C tutorials
<hcarty>
joelr: I think the example in the manual does some basic caching/validity checking
<hcarty>
adrien: Once that part is done, Lwt can use the file descriptor provided by zeromq to do its select/polling
<hcarty>
The part I'm unsure of is how to tell Lwt "wake this thread up and execute it at HH:MM:SS"
<hcarty>
adrien: That part works. Lwt and zeromq play nicely together that way.
<hcarty>
adrien: But some tasks need to be sent at specific times so I am looking for a clean way to implement that piece.
<hcarty>
adrien: It is sent using zeromq, so the receipt of a task by a worker is event driven
<adrien>
hcarty: would the task pool be able to send events over a file descriptor?
<hcarty>
flux: The source being checked (a task pool) is unaware of the process(es) doing the checking (workers who perform tasks)
<hcarty>
flux: That's part of the situation I'm in. I want to wait approximately n seconds before checking on a condition again, OR wait until some event arrives which may change the result of the checked condition.
<hcarty>
pippijn: Perhaps. But sleeping doesn't block other threads and (I think) can be canceled safely.
<hcarty>
The memory use arguments don't really apply, but I wouldn't be surprised if the general idea of 'sleep implies flawed logic' applies.
<pippijn>
hcarty: probably even more, because there is no preemption
<hcarty>
pippijn: That's what I expect. I'd be curious to know how much that article applies to Lwt-type threads.
<hcarty>
diml: How reliable is the timing of Lwt_unix.sleep?
<hcarty>
pippijn: camlidl does a reasonably good job for the areas it covers
<hcarty>
pippijn: ciml does a bit of that, and camlidl does a lot of it
<hcarty>
pippijn: Something that an automated tool generally doesn't have
<hcarty>
pippijn: That's true
<hcarty>
camlidl isn't actually that bad for simple interfaces. But it's old and not well supported by modern tools.
<hcarty>
It certainly wouldn't hurt to have a nice, up-to-date tool for (mostly) automating the generation of clean C bindings.
<hcarty>
pippijn: Do!
<hcarty>
pippijn: adrien has written some tools as well, but I don't know what state they are in.
<hcarty>
pippijn: ciml provides some camlp4 magic to make writing bindings a bit cleaner. camlidl automates part of the process if header files are setup properly. swig can produce ugly bindings.
<hcarty>
f[x]: I've used camlidl a few times, but I'm trying to move away from it. At least as build-time dependency.
<hcarty>
pippijn: There are a limited number of C libraries that people need. People have generally wrapped the ones they need by hand, or with some assistance from something like camlidl.
<hcarty>
pippijn: Why not what?
<pippijn>
hcarty: why not?
<hcarty>
rly: I don't think that there has been enough demand for completely automated C bindings from OCaml. There are a number of tools and libraries to help with the process, but nothing that is 100% automated.
2012-05-07
<hcarty>
diml: Ok, just curious. I'd like to have a timeline in an Lwt-using project. Rtime looked potentially interesting since Lwt comes with React support already.
<diml>
hcarty: i don't know Rtime very well
<hcarty>
diml: Do you know of an implementation of Rtime with Lwt's React wrapper?
<hcarty>
gildor_: Neither do I - the blind providing emacs support I suppose :-)
<gildor_>
hcarty: maybe, I don't use emacs and I don't use typerex
<hcarty>
But I don't remember the details of the fix or its effects
<hcarty>
gildor_: Ah. I think there was a solution though, even if it did disable some functionality...
<hcarty>
joelr: Good luck :-)
<joelr>
hcarty: i'll look, thanks
<hcarty>
joelr: I'm not sure. I think this was on the main OCaml mailing list
<gildor_>
hcarty, joelr: I think there is a problem with socket handling on Mac with emacs
<hcarty>
joelr: There is likely something on the TypeRex site about it
<joelr>
hcarty: is there a mailing list?
<hcarty>
joelr: IIRC the solution was to turn something off
<hcarty>
joelr: I don't use either, but I've read that others have had the same issue
<hcarty>
mrvn: Not that I know of... maybe you could with recursive modules?
<mrvn>
hcarty: can you pass the "self" module around?
<hcarty>
mrvn: That's where I have ended up passing modules around. It's a bit more verbose in some cases than records but the intent can be clearer.
<mrvn>
hcarty: I would pass a module around if I need to pass more than one closur from a module I think. Seems easier than to build a record of closures.
<hcarty>
Apply the functors in a function and pass the resulting modules around
<hcarty>
mrvn: Somewhat. You could mix the two.
<hcarty>
mrvn: Or pass around modules in somewhat rare cases
<hcarty>
mrvn: rec or functors if it helps get rid of the recursion
2012-05-04
<hcarty>
abdallah: But you can use ocamlbrew to build OCaml 3.12.1 (or svn or any other version) and have it automatically setup odb and install Batteries
<hcarty>
abdallah: I think odb works with 3.11, but I'm not certain
<hcarty>
abdallah: odb makes installing Batteries, among other libraries, much easier
<hcarty>
abdallah: I can with 1.x, but that should be much easier with 2.0 when it comes out
<hcarty>
abdallah: It's worth making the switch
<hcarty>
abdallah: You're welcome
<hcarty>
abdallah: And streams and sequences and other lazily evaluated structures
<hcarty>
abdallah: Batteries provides a lazy list module so you don't need to create your own
2012-04-27
<diml>
hcarty: the fd returned by ZMQ is a socketpair which i think is just used for notifications, that's why it must be monitored for read
<hcarty>
diml: I've been away for a bit, but I did get a block eventually.
<hcarty>
diml: I may try changing the send wrapper to use Lwt_unix.Read as well
<hcarty>
It does go into the retry function, but never more than once.
<hcarty>
diml: It has not yet
<hcarty>
Without the retry loop it had usually failed by now
<hcarty>
diml: It hasn't failed yet
<diml>
hcarty: no (well yes... but it won't be pretty), but according to this the fd must only be watched for read events
<hcarty>
diml: Is this possible in Lwt (watching for both read and write events)?
<hcarty>
The syntax is similar for objects but I don't remember it off the type of my head. It's in the manual in the object section...
<hcarty>
For records, the syntax is: let new_record = { original_record with field_x = new_value }
<hcarty>
Hodapp: If an object has 200 attributes and you want a new object with only two of those changed, the other 198 will be shared between the objects
<hcarty>
OCaml's objects support functional updates, so you don't need to copy (much of) anything.
<hcarty>
everyonemines: Indeed - thanks for sharing the link
<hcarty>
If the Makefile isn't structured to be -jN friendly then it doesn't really matter what the underlying language is.