2010-11-04

<hcarty> orbitz: I think you're right
<hcarty> joko: I may have the syntax a bit off, but it's something close to that.
<hcarty> joko: You need something like "type 'a t = { 'a t_intmap : 'a IntMap.t ; ... }

2010-11-03

<hcarty> I really like that OCaml, for most of the core language, doesn't require any type annotation.
<hcarty> dark: The length of the generated errors can become cumbersome at times without extra type annotation
<dark> hcarty, but even the sml's way of ad hoc overloading feels better, imo :(
<dark> hcarty, mhmmm.. well, yes, but ocaml's type errors are actually nice.. a lot of things are turned into class names
<hcarty> dark: And the type errors become much harder to read :-)
<hcarty> pa-do and local module open can make things a bit murkier, but ( + ) still only means one thing in a given context.
<hcarty> OCaml's lack of operator overloading/type classes bothered me at first, but now I like the clarity it provides
<hcarty> Haskell... It's typo time.
<hcarty> How is it broken when compared with Haskell? (I'm only slightly familiar with Hashell)
<hcarty> Oops, languages rather
<hcarty> dark: How is it broken when compared with other languageS?
<hcarty> dark: That said, having Module.( ... ) built in to the language now is a wonderful thing
<hcarty> dark: True, but pa-do adds some other magic
<bitbckt> what hcarty said. :)
<hcarty> devinus_: Some combination of pa_do (http://pa-do.forge.ocamlcore.org/) and Num should help
<hcarty> devinus_: There are arbitrary precision number modules around
<hcarty> dark: They are
<hcarty> devinus_: Large precision?
<hcarty> I think!
<hcarty> It does
<hcarty> adrien: Ah, ok. Sorry for the noise then :-)
<adrien> hcarty: afaict, no, it doesn't: what it seems to provide is a way to run cooperatively the computations as in "React.E.fold (fun a b -> ...) a0 bl": the anonymous function would run cooperatively each time
<hcarty> I haven't used it, but that may be part of why it's provided
<hcarty> adrien: Does Lwt's React wrapper handle this?

2010-11-02

<hcarty> :-)
<hcarty> Python
<hcarty> orbitz: That's a horrible thing to say.
<hcarty> I haven't tested this, but I've read in a few places that keeping the "external" form in a .mli leaves some extra options available to the compiler
<hcarty> adrien: It apparently affects some optimizations
<hcarty> _y_: Are you putting "external ..." in the .mli and the .ml?
<hcarty> gildor: Thank you again!
<gildor> hcarty: Sys.command should do in most case and is probably more simple to use
<hcarty> Any suggestions for a "mkdir -p" equivalent in OCaml, or am I better off using a Sys.command call for now?
<hcarty> gildor: Ok, thank you
<gildor> hcarty: not yet, but probably for 0.5.0
<hcarty> Does ocaml-fileutils' mkdir permission/mode setting work in the latest version?

2010-11-01

<hcarty> Very nice
<mfp> hcarty: it handles prepared statement caching, param binding, data extraction, error checking (including automatic stmt reset to avoid BUSY/LOCKED errors in subsequent queries), stmt finalization on db close, etc.
<hcarty> s/to the/beyond/
<hcarty> mfp: Sqlexpr looks interesting. Does it add anything to the to Batteries Print.* functions' special syntax?

2010-10-29

<hcarty> That makes sense
<hcarty> It sounds like the class definition may be extraneous
<hcarty> dark: Could you use the "object method foo = x method bar = y end" syntax?
<flux> hcarty, thanks for the pointer! I've copy/pasted/modified my very own inventory-app already ;-). (well, it almost works)
<hcarty> Not sure that it's a full-blown CRUD, but it's part of the puzzle
<hcarty> I think that's the one
<flux> hcarty, well, if there is, google doesn't know about it, or it doesn't call it crud :)
<hcarty> flux: There was a blog post about this...
<hcarty> gildor: Thanks, I'll take a look and provide what feedback I have
<gildor> hcarty: tell me, if it is ok and what I can improve
<gildor> hcarty: could you watch some videos and made constructive criticism about them, so I can improve the remaining video I have to do
<gildor> hcarty: can I give you some homework?
<hcarty> gildor: Yes, indeed
<gildor> hcarty: you told me that you want to see video from CUG 2010?
<hcarty> With completion on "A.init"
<hcarty> For example: module A = Array let a = A.init 10 0
<hcarty> Is there a way to have the Lwt toplevel perform automatic completion on aliased and open modules, in addition to the full, original value's path?
<ski> hcarty : interesting .. ty
<hcarty> ski: http://www.pps.jussieu.fr/~li/software/index.html#enhtop -- This should do what you want
<hcarty> ski: There are a number of toplevel patches floating around - one of them may support printing type defintions

2010-10-28

<melwtech35> hcarty: thanks that works
<hcarty> Or returns the original string if no modifications are needed
<hcarty> In this case, it escapes the string
<hcarty> orbitz: Indeed.
<hcarty> And the function is String.escaped, not String.escape in the OCaml stdlib
<hcarty> melwtech35: I think there is a String.escape or similar in the standard library, if that's what you're looking for

2010-10-27

<hcarty> adrien: Thanks for the link - that looks quite cool
<hcarty> I think they both support compilation, but I don't know how either of these are done
<hcarty> Both emacs and vim have support for (at least) calling make with various targets
<hcarty> That may have been luck more library capability
<hcarty> I've only used it once, but for that one project it worked where xml-light did not.
<hcarty> And PXP is somewhere in between, from what I understand
<hcarty> orbitz: You could use CDuce if the whole project is XML-based
<hcarty> orbitz: I'm not sure if it's any more useful in this case than the generic printf, but Batteries has Print.printf which allows you to write custom printers for your types.

2010-10-26

<hcarty> Not to mention JoCaml and Camlp3l
<hcarty> Between ocamlnet and ocamlmpi there should be decent support for cluster computing in OCaml
<hcarty> That's good to hear - better cross platform support is always nice
<hcarty> gildor: I've never used it, just heard complaints. But that was a while ago, and I've never attempted it myself.
<gildor> hcarty: just consider that OCaml can compile with msvc/cygwin/mingw
<gildor> hcarty: well Windows support for OCaml is not that bad
<hcarty> grettke: There does some to be some mix between users. However, F# is rather weak in its Linux support, and OCaml is (from what I understand) similarly weak in its Windows support
<hcarty> Indeed
<hcarty> roconnor: I'm very not familiar with Haskell, but the signatures look similar
<hcarty> roconnor: List.for_all?
<hcarty> Eventually
<hcarty> It sounds like OASIS-DB may be able to do something like that
<hcarty> Provided in a generic manner, so the logic doesn't need to be duplicated for every packages
<hcarty> adrien: That would be excellent - a "godi-foo-vcs" package which always pulls and rebuilds from a given repo branch
<hcarty> Yes, GODI's patch management could use some help. It's been easier to create new packages of the patched code at times.
<hcarty> adrien: Submitted upstream, I hope :-)
<hcarty> You're welcome - glad to help
<hcarty> The type errors are clear as mud until you understand what they're telling you :-)
<hcarty> Not a string
<hcarty> Ok, then you need to give it a char
<hcarty> What is codage?
<hcarty> code string codage
<hcarty> No
<hcarty> "val code : 'a -> 'a codage -> string"
<hcarty> You have it backwards
<hcarty> Right
<hcarty> code foo codage
<hcarty> hurrycane: You have it backwards
<hcarty> Well, that's how it would be called :-) What's the error?
<hcarty> code foo codage
<hcarty> hurrycane: I think you have a bit of a mixup in terminology - Codage is a module, while codage is a value
<hcarty> hurrycane: I can't spend much time, but this may help - http://www.ffconsultancy.com/products/ocaml_for_scientists/chapter1.html
<hurrycane> @hcarty any ideas?
<hcarty> hurrycane: Go ahead and ask - if someone is able to help, they will.
<hcarty> ocamlscript can be installed from GODI. I'm not sure if it's available for Debian, Ubuntu and Fedora.
<hcarty> thelema: Would it be worth adding an ocamlscript example to the Batteries documentation/examples? That may provide a slightly easier way to get up an running with Batteries, at least for people with ocamlscript available

2010-10-25

<adrien> hcarty: great, thanks a lot, even if saffire is old and unmaintained it's good to know it
<hcarty> latest revisions that is
<hcarty> stdDoubt: The latest version of the GSL bindings are here - http://code.google.com/p/ocamlgsl/
<hcarty> stdDoubt: The GSL bindings for OCaml are pretty well done
<hcarty> stdDoubt: Does GSL provide what you want?
<hcarty> A similar tool mixed with something like Ciml (and/or OCaml cowboy?) may help provide safer bindings.
<hcarty> I tried it shortly after learning OCaml but I didn't have any luck getting it to work
<hcarty> gildor: Indeed
<gildor> hcarty: but full of promises
<hcarty> adrien: http://www.cs.umd.edu/~furr/saffire/ - but it appears old and potentially unmaintained.
<hcarty> adrien: Saffire is the OCaml-C interface checker

2010-10-22

<hcarty> Or let b = ref None
<hcarty> Like flux's "let a = Hashtbl.create 42" example
<hcarty> kaustuv: My guess is that it would make some imperative operations more difficult and/or verbose

2010-10-21

<ezyang> ah, ok. I was wondering if there was a way to do it inline not hcarty's way.
<hcarty> dark's answer is the better way, generally (.mli)
<hcarty> ezyang: You can (ex: let f (x : int) : int = x + 2)
<hcarty> If you look at the first line of the bytecode output, it has a #! line pointing to ocamlrun
<hcarty> ezyang: ocamlrun
<hcarty> ezyang: Use ocamlopt in place of ocamlc for native code compilation
<hcarty> roconnor: But very promising
<hcarty> roconnor: OASIS is rather new
<hcarty> gildor: Thank you!
<gildor> hcarty: ^^^
<gildor> hcarty: yes
<hcarty> gildor: Is there a changelog (WIP or final) for OASIS 0.1 -> 0.2?
<roconnor> hcarty: thanks
<hcarty> roconnor: IIRC, Jason Hickey's book has a nice section on functors
<hcarty> roconnor: It is kind of terrible
<hcarty> flux: It sounds like gildor is getting ready to roll out a new release of OASIS soon
<hcarty> (project by gildor to create an easier OCaml build system and a CPAN-like system for OCaml packages)
<hcarty> OCaml packaging should become significantly better once OASIS and OASSIS-DB take off
<hcarty> It's a more advanced task, but it's even relatively straightforward to setup your own local packages
<hcarty> among GODI's available packages that is
<hcarty> Ocsigen and its dependencies are among its available packages
<hcarty> manveru: GODI is probably your best bet in that case
<hcarty> It builds OCaml and a large number of OCaml packages from source
<hcarty> GODI should help with that
<hcarty> ocamlnet has a server framework
<hcarty> manveru: For OCaml projects?

2010-10-20

<hcarty> ocamlrt has something similar, and I really wanted to be able to use that syntax :-)
<hcarty> adrien: That hbox [ ... ] code is the main reason I started Gtk-light
<adrien> hcarty: something I'm missing in lablgtk2 is an easy way to create layouts, pretty much what you have line 16 on http://0ok.org/cgit/cgit.cgi/gtk-light/tree/basic_gui_test.ml
<hcarty> But the idea is really cool
<hcarty> The internals get pretty hairy in places
<hcarty> I think the second one is more up to date
<hcarty> adrien: http://code.google.com/p/ocamlrt/ and svn://osprepo.janestcapital.com/osp/2007
<hcarty> It was one of the 2007 projects IIRC
<hcarty> adrien: If it's useful for your FRP GUI code you're more than welcome to use it
<hcarty> adrien: My original intent with Gtk-light was to lift some of the ideas from the Jane St. FrpGui. I never got to the FRP portion, but I managed to steal some function names and a bit of the calling convention...
<albacker> thankyou hcarty
<hcarty> albacker: lablgtk2 is probably your best bet. I started a Gtk-light library, but it's far from complete and I haven't had time to develop it further: http://0ok.org/cgit/cgit.cgi/gtk-light/
<hcarty> ezyang: Yes, the tutorial has a lot you won't need :-) But it has a lot of pointers to other material as well
<hcarty> ezyang: http://www.ocaml-tutorial.org/, the OCaml manual (particularly the intro chapter), Jason Hickey's book - http://www.cs.caltech.edu/courses/cs134/cs134b/book.pdf
<adrien> hcarty: no prob, didn't take me much time since I had already dug in ocamlbuild a bit :-)
<hcarty> adrien: Thanks again for the extra testing and feedback. With luck, fixes will make it in to 3.12.1 myocamlbuild.ml files will become needed a little less
<adrien> hcarty: ok :-)
<hcarty> adrien: I added a note to the report stating that it appears to be missing for (at least) linking and inferring a module's interface

2010-10-19

<adrien> hcarty: did you mention what I said about link-time vs. compile-time in the mantis bug report ?
<hcarty> adrien_mib: Thank you - would you mind updating the Mantis report with this information?
<adrien_mib> hcarty: yeah, I think it's a bug
<hcarty> That... is odd
<adrien_mib> hcarty: my bad, I hadn't tried the whole combination and I also have the problem
<hcarty> I was hoping to eliminate the need for a myocamlbuild.ml for simpler projects
<hcarty> adrien: I have been using a custom myocamlbuild.ml, modified from the Batteries example
<hcarty> Compilation line: ocamlbuild -use-ocamlfind -pkg threads -pkg batteries foo.native
<hcarty> foo.ml: open Batteries let () = print_endline "Hello world"
<hcarty> _tags: <*>: thread
<hcarty> Wow, still no luck
<hcarty> :-)
<hcarty> adrien: That's odd ... '-tag thread' doesn't work
<adrien> hcarty: <*>: thread
<hcarty> adrien: Would you mind putting up your _tags in a pastebin?
<adrien> hcarty: I used a _tags with "thread"
<hcarty> I get the same "Missing -thread or -vmthread switch" with foo.byte or foo.native
<hcarty> I used: ocamlbuild -use-ocamlfind -pkg threads -pkg batteries foo.inferred.mli
<hcarty> adrien: Could you try generating an interface with ocamlbuild + ocamlfind + batteries?
<hcarty> adrien: It showed the failing command line
<adrien> hcarty: you used -classic-display to get the command-line?
<hcarty> Since the Batteries module requires threads
<hcarty> adrien: I ran in to the problem when using Batteries + ocamlbuild 3.12 + ocamlfind
<hcarty> I submitted a bug in Mantis, but I'm wondering if I missed something
<hcarty> When linking with the threads package
<hcarty> "-thread" paramter with ocamlfind
<hcarty> adrien: Yes - ocamlbuild doesn't seem to use the
<adrien> hcarty: something with threads in particular?
<hcarty> Has anyone here used ocamlbuild 3.12's ocamlfind support + threads?

2010-10-18

<hcarty> ftrvxmtrx: Thanks! I submitted a bug in the Batteries bug tracker
<ftrvxmtrx> hcarty, confirming, saw the same thing yesterday while playing with first class modules
<hcarty> http://ocaml.pastebin.com/vEk4fvFL -- this consistently gives me the problem (be ready with Ctrl-C...)
<hcarty> Is there anyone here with Batteries and OCaml 3.12 who can confirm?
<hcarty> when entered in the toplevel
<hcarty> thelema: It prints a (seemingly) infinite series of (
<hcarty> thelema: One of the Batteries syntax extensions seems to have a problem with this function definition: let f (type s) m = let module M = (val m : S with type t = s) in let f (x : s) = x in f;;
<hcarty> You're welcome
<junis> thank you hcarty
<hcarty> junis: Double
<orbitz> hcarty: yeah i was just tryign to get a testcase, i see where i mssed up though
<hcarty> orbitz: Why not use M.map?
<hcarty> It does seem to be possible using first class modules if a bit of extra annotation is used
<hcarty> rossberg: Ok, thanks. I wasn't sure if there was a way to pull it off using first class modules.
<rossberg> hcarty: no, when there are type dependencies between argument and result like that you need to use a functor
<hcarty> I think I remember seeing a blog post or article about using 3.12's first class modules for this, but I haven't been able to find it
<hcarty> Is it possible to make a function like : val make : (module M) -> (M.t -> unit) * (unit -> M.t)
<gildor> hcarty: take your time, I am preparing OASIS v0.2 release, so I am pretty busy
<hcarty> gildor: Yes, will do - it may take me a little while to get a chance to do so, but I will as soon as possible.
<gildor> hcarty: not in the toplevel, I am not surprised
<hcarty> gildor: The GODI package currently uses a patched snapshot of the code
<hcarty> ocamlmpi in its current state doesn't seem to work in the toplevel from what I can tell.
<hcarty> gildor: The to (somewhat) large changes I propose are (1) convert comments in mpi.mli to ocamldoc comments and (2) update the build system
<hcarty> gildor: Yes, with a few patches. I think it would worth making a few extra changes before a release
<gildor> hcarty: with patches, I suppose
<hcarty> gildor: ocamlmpi is in GODI now, and hopefully working properly.
<adrien> hcarty: I've started using it with lablgtk (and more generallly, APIs with side-effect) pretty successfuly but now I need to "blend" several signals/events into a single one: react provides that for {1,6}-uplets but I need it for arbitrary records

2010-10-17

<hcarty> FRP seems like it could be interesting as a way to express message passing.
<hcarty> adrien: Agreed re: FRP
<hcarty> As far as I know, Batteries does not have an equivalent to Core's Shell module
<hcarty> orbitz: I don't think that there is any C in Batteries, so it should be fairly portable.
<hcarty> orbitz: I'm not sure - I spend all of my time on Linux. I think that some of the developers use other OSs.
<orbitz> hcarty: how is batteries for other OS's?
<hcarty> IIRC, somewhere in their blog posts/documentation/source comments, the authors mention that Core is only heavily tested on Linux
<hcarty> orbitz: I've toyed with it a bit, but I use Batteries primarily

2010-10-15

<hcarty> The documentation is sparse, so I'm not sure if I'm doing something incorrectly.
<hcarty> It does not seem to support building with threads
<hcarty> Has anyone here tried ocamlbuild 3.12.x's support for ocamlfind?
<hcarty> orbitz: Announcements/other information on the forge would be handy as well, if they are generally useful
<hcarty> Yoric: I'm not sure how to reply to your answer directly on stackoverflow, but for what it's worth - the Batteries string and super-printf extensions are still included in the latest Batteries releases

2010-10-14

<adrien> hcarty: haven't had troubles with 3.12 except the camlp4 incompatibilities but now it's solved (I was using mikmatch) so I mostly switched to it
<hcarty> adrien: I have the same (3.11.2 and 3.12.0), and have been enjoying experimenting with 3.12.0's new features.
<adrien> hcarty: yeah, 3.12
<hcarty> adrien: 3.12?
<hcarty> Once Batteries moves to 3.12
<hcarty> This should greatly simplify the Batteries-provided myocamlbuild.ml
<hcarty> adrien: Thanks for the ocamlbuild pointer
<hcarty> I generally rely on ocamlbuild or OCamlMakefile for more complex modules
<hcarty> adrien: Nifty! How?

2010-10-13

<hcarty> adrien: Indeed :-) But it's the kind of crazy I'm glad exists.
<hcarty> 'print_endline (show (option int * string) (Some 3, "four"));;' with no syntax extensions involved
<hcarty> Using Array.make with a mutable value that is
<hcarty> pierreN: You're welcome - I've run in to the same problem in the past :-)
<pierreN> hcarty: thank you (gaah that was obvious)
<hcarty> stdDoubt: Both work, but the mli is the more common approach
<hcarty> stdDoubt: Generally the .mli, as it makes it easier to install/provide the .mli with the compiled library, without requiring the full source code
<hcarty> pierreN: You could make the array, then replace each element with a fresh queue.
<hcarty> pierreN: Ah, I'm not sure then - I've never used caml light. Does it not have an Array.init?
<pierreN> hcarty: i'm sorry but i'm using caml light
<hcarty> pierreN: Creating a new Queue.t for each element, of course
<hcarty> pierreN: See Array.init
<hcarty> pierreN: That's only with Array.make
<hcarty> pierreN: Not sure I understand the question. You could initialize an array with queues as the values in the array.

2010-10-12

<hcarty> sdschulze: I do not, but I'm more of a "OCaml as a means to non-CS ends" user
<sdschulze> hcarty: OK -- I'm currently trying to understand unification...
<hcarty> oriba: I'm not sure if there are videos available, but CUFP 2010 and co. hadescribed in one of the FAQs
<hcarty> http://www.math.nagoya-u.ac.jp/~garrigue/papers/ml2010-show.pdf -- this has some code samples which, I think, take advantage of the simplified packing/upacking syntax
<hcarty> The talks from the 2010 Baltimore meeting(s) are certainly impressive
<hcarty> That will hopefully reduce the syntax overhead
<hcarty> There is a development branch for OCaml which looks like it is attempting to simplify the first class module packing and unpacking syntax

2010-10-08

<hcarty> flux: "open Foo(Bar)" does not seem to
<hcarty> flux: Doesn't "include Foo(Bar)" work?
<thelema> hcarty: it's basically ok. I might dedicate an exception for range check failures, maybe Constraint_Error

2010-10-07

<hcarty> gildor: Send the patch that is. Does that sound reasonable?
<gildor> hcarty: ok
<hcarty> gildor: I'll send the patches to you for now. If I end up making any more changes I'll request commit rights.
<gildor> hcarty: do you want to have commit rights ?
<gildor> hcarty: send me patches and tell me when you want a release
<hcarty> gildor: I may end up wrapping a few others as well. Would you prefer patches as I go, or a single patch with the final result?
<hcarty> gildor: I've wrapped a new function for ocamlmpi (iprobe, a non-blocking probe)
<gildor> hcarty: pong
<hcarty> gildor: ping
<hcarty> thelema: Does that basic structure look ok to you (the Limited module example)? If so I'll try to get it more fleshed out and properly submitted for inclusion over the next few weeks.
<thelema> hcarty: very interested. I've wanted this for a long time

2010-10-06

<hcarty> PascalHunger: It's here! Except it's spelled 3.12.0...
<hcarty> adrien: Prior art! That's promising at least. I know I've seen examples for this sort of thing in OCaml, but I don't remember where
<hcarty> Though probably more fleshed out...
<hcarty> http://codepad.org/HeWHjsg8 -- something along these lines
<hcarty> thelema: Any interest in a limited range module/functor for Batteries? For example, integers which are restricted to being 1 <= x <= 10.