2012-10-22

<hcarty> ker2x: They claim to use OCaml for sys admin purposes :-) But I don't know any details regarding how they do so.
<ker2x> hcarty: i follow Jane St. RSS
<hcarty> ker2x: Jane St., Citrix and others use it for general applications as well
<hcarty> ker2x: I liked both but I found OCaml to be more accessible and better suited to my tastes.
<hcarty> ansx: Less trolling please. Reasons to use one language vs the other = good; Blanket statements bashing one language without reason = bad
<ker2x> hcarty: acutally, that's what i tought. Haskell is very fun but OCaml seems to be more "real world oriented". not sure why.
<hcarty> So you now have two data points to work from :-P
<hcarty> ker2x: I started learning Haskell, found OCaml, then stuck with OCaml for 'real' work

2012-10-19

<fasta> hcarty: there was another bug, but now it works.
<hcarty> ack... can't even type the correction properly...
<hcarty> s/the/string the/string to the/
<fasta> hcarty: right, how silly of me.
<hcarty> fasta: You need to add the length of the matched string the index of the first matched character
<fasta> hcarty: can you see why this loops forever? http://paste.kde.org/574280/
<hcarty> fasta: Libraries, loading compiled code/reading source code, changing warning/error settings
<fasta> hcarty: it seems a rather important feature that it's easy to switch between interpretation and compilation mode.
<fasta> hcarty: those are used for libraries.
<hcarty> fasta: The toplevel has a few toplevel-specific directives. Beyond that, which differences are you asking about?
<hcarty> fasta: Or the PCRE bindings
<fasta> hcarty: thanks
<hcarty> let _, stderr = syscall "my command" in ...
<hcarty> fasta: The second version there should give something close to what you're looking for if you ignore the stdout return value
<hcarty> thelema: That makes sense
<hcarty> fasta: I don't remember. I don't think so, but it's been a while since I wrote code using this.
<fasta> hcarty: do I have to read everything from stdout if I only care about stderr?
<hcarty> [| a; b; c |] is the array literal syntax
<hcarty> fasta: [||]
<hcarty> The only place I have mostly-complete completion support is in the toplevel with utop.
<hcarty> fasta: I haven't put much effort into being able to have completion like that, but it's something I would love to have.
<hcarty> fasta: Sadly no
<hcarty> fasta: Sometimes another editor like Komodo Edit if I need to edit remove files
<fasta> hcarty: and do you have stuff like completion working with 100% accuracy?
<hcarty> fasta: vim usually
<fasta> hcarty: or did you build something yourself?
<fasta> hcarty: what do you use to edit OCaml code?
<hcarty> The documentation is fairly sparse though.
<hcarty> Lwt arguably provides a better API for handling external processes - http://ocsigen.org/lwt/api/Lwt_process
<hcarty> fasta: If the function didn't take an environment argument then someone who did care about the environment would be out of luck
<fasta> hcarty: thanks for your useful replies.
<fasta> hcarty: yes, I know.
<hcarty> fasta: would work
<hcarty> fasta: My guess is that either passing an empty array or then result of Unix.environment ()
<fasta> hcarty: the API doesn't seem to provide something for that case, because it simply enumerates some combinations.
<fasta> hcarty: and also in this case, I don't care about the environment, but I do care about stderr and stdout.
<hcarty> fasta: I agree that it's unclear. I had the same question about open_process_full.
<hcarty> fasta: You could submit a bug report with or without a patch to the bug tracker
<hcarty> fasta: Unix.environment's documentation - "Return the process environment, as an array of strings with the format ``variable=value''."
<hcarty> fasta: It may be explained elsewhere in the Unix module documentation

2012-10-18

<TDJACR> Error: This expression is not a function, it can't be applied, with a red line under the match block hcarty

2012-10-17

<hcarty> thomasga: I'm also trying to evaluate opam + ? vs ocamlbrew + (odb and/or opam) vs GODI + (odb and/or opam) for my own use.
<hcarty> thomasga: Among other things, it gives me some idea of where ocamlbrew will/would fit in the OCaml ecosystem once opam is released in a stable state.
<hcarty> thomasga: That's not surprising. I'm curious to see if opam is useful in its current state on a system without OCaml.
<hcarty> thomasga: That's the error I get after running './opam64 init -comp 3.12.1'
<hcarty> thomasga: 'File /home/hcarty/.opam/compilers/3.12.1.comp does not exist'
<thomasga> hcarty: actually 'opam init -comp 3.12.1' should work
<hcarty> thomasga: Ok thanks. I'll try again after it's been updated :-)
<hcarty> thomasga: For reference, I'm trying to use the instructions here - http://opam.ocamlpro.com/doc/Quick_Install.html
<hcarty> thomasga: Nothing gets downloaded from what I can see. top doesn't show any activity either.
<hcarty> With '--verbose' I get a curl status display that never shows any progress
<hcarty> thomasga: 'Cannot download 3.12.1/urls.txt, please check your connection settings.'
<hcarty> thomasga: './opam64 init 3.12.1' sits and doesn't appear to do anything
<hcarty> thomasga: Does the opam64 binary still require an existing OCaml installation?
<hcarty> thomasga: './opam64 init' doesn't work for me on an Ubuntu 12.04 64bit install. It tells me 'File /home/hcarty/.opam/compilers/system.comp does not exist'

2012-10-16

<hcarty> I found that really helpful when I started out
<_andre> hcarty: yeah i know it... i was looking for a gentler introduction to recommend to a friend
<hcarty> _andre: Jason Hickey's book is particularly nice
<hcarty> _andre: I haven't read it, but there is a decent list here - http://www.ocaml-lang.org/books.html
<hcarty> ng__: I'm across the Atlantic
<hcarty> estrelinhas, not 睡觉 :-) I doubt the second is Portuguese
<hcarty> Portuguese maybe?
<hcarty> pippijn: That's definitely the standard approach
<hcarty> ng__: Good luck and have fun :-)
<ng__> hcarty, ah yes, you're right, I'm changing everything, just a little time
<hcarty> ng__: Some of these tutorials may be useful - http://www.ocaml-lang.org/tutorials/index.html
<hcarty> ng__: Otherwise you end up with ambiguous/incorrect syntax.
<hcarty> ng__: You either need to add lots of ;; between your statements and definitions, or you need to wrap everything in lets
<hcarty> ng__: You are missing ;; between expressions or wrapping them in let .. = .., as in the example I pasted.
<hcarty> ng__: http://pastebin.com/U7BHALMj -- same thing but with extraneous ( ) removed
<hcarty> That works here - I can copy and paste it into the toplevel and it runs and produces output
<hcarty> ng__: Sorry - I left an error in there when I made my earlier edit
<ng__> hcarty, here is thhe code, I use "=" in line 11
<hcarty> ng__: Is the using the code I replied with, or something else?
<hcarty> adrien: Indeed, those both should be changed. But it shouldn't be the cause of the type error.
<hcarty> Or pastebin the whole piece of code ... that looks like it will need some context.
<hcarty> ng__: What is on line 11?
<hcarty> ng__: The usual way to handle this is to wrap all expressions in let ... = ...
<hcarty> ng__: If you have bare expressions outside of a 'let' definition they need to be separated by ;;
<hcarty> ng__: Here's a (mostly untested) edit - http://pastebin.com/EpX68Ds5
<hcarty> Or you could wrap your code in an outer "let () = ..."
<hcarty> There are a few ways to fix it. You could add ;; after your print lines.
<hcarty> ng__: It's kind of a formatting issue
<hcarty> ng__: Go ahead and ask your question(s), you don't have to ask to ask. Can you pastebin the problematic code somewhere? That will probably be necessary to get a good answer.
<hcarty> Or incr gasche; ...
<hcarty> gasche++
<hcarty> Spell checking in the compiler! http://caml.inria.fr/mantis/view.php?id=5768

2012-10-13

<adrien> hcarty: well, Batteries came first if you take extlib into account :P
<hcarty> Core works hard to be consistent with its own standards. Batteries is designed to be (almost entirely) compatible with the stdlib out of the box.
<hcarty> Core requires a signed contributor agreement before contributions can be made, Batteries does not
<hcarty> Batteries was started/released before any public releases of Core were made.
<hcarty> wieczyk: I think Core existed first, but only as an internal project/library. Core's development has been opened up somewhat, but it is still closely tied to Jane St. Batteries began and continues as a community project.

2012-10-12

<hcarty> pima: It works here under Linux + OCaml 4.00.1

2012-10-11

<thelema_> hcarty: cheers
<wmeyer> hcarty: I think we had quite few proposals
<hcarty> thelema_: Some sort of module/namespace mixing
<hcarty> thelema_: I need to run, but I'm not sure that something new should be added. That's just the impression I got regarding what the namespace branch in OCaml svn was doing.
<thelema_> hcarty: why shouldn't Calendar be a module?
<hcarty> thelema_: If Calendar = module, then that's a problem. If Calendar <> module then it's not a problem.
<hcarty> thelema_: That would be nice
<hcarty> thelema_: Exactly
<hcarty> Or beyond
<hcarty> Maybe in 4.01 :-)
<hcarty> I think that there's a big benefit. For example, I have local code to mix Batteries' IO support in CalendarLib.
<hcarty> But it would be nice if Core.Enum were possible without recompiling Core
<hcarty> s/put/design/
<hcarty> I'm not sure of the right way to put it
<hcarty> thelema_: I don't know. It would be nice to not have these general namespaces locked out.
<hcarty> thelema_: It is nice, though, that in the Perl world Net::FTP and Net::SCP can be separate entities
<thelema_> hcarty: actually, I'm not too concerned about that; it's sufficient for the toplevel namespace to be 1:1 with project names
<hcarty> It would be nice if Batteries.Array could be provided by a different library than Batteries.Calendar
<hcarty> That's something I miss from Perl when writing/extending code in OCaml
<hcarty> thelema_: Proper/more flexible name spaces would help there
<thelema_> hcarty: exactly; some of them don't really apply; stringable is obseleted by printable
<hcarty> It would be nice to have Ord(er)able, Printable, ...
<hcarty> Ah, ok. So BatOrd may stay in Incubator, but every comparable module should have a val ord : t -> t -> (Gt | Lt | Eq)
<hcarty> No per-module ord in the 2.0 release, is that correct?
<hcarty> thelema_: Understood :-)
<thelema> hcarty: great. Now I just wish I could make the time to fix up batteries for a 2.0 release
<hcarty> thelema: I'm happy with BatBounded staying in Incubator for a release or two. I'd rather have it right later than wrong now and be stuck with it.
<hcarty> fx_: Thanks indeed!
<hcarty> vbmithr: It did initially, but IIRC pa_do was modified to get around that
<hcarty> As far as I know there is no universal list of syntax extensions, but the Caml Hump likely has the biggest ones
<hcarty> djcoin: I think you're correct on the AST manipulation additions. They look like they could make it into 4.01.
<hcarty> Some can be used to build other extensions, including pa_do
<hcarty> djcoin: In that some can be used together
<hcarty> djcoin: Some are
<hcarty> vbmithr: Beat me to it :-)
<hcarty> djcoin: I don't know the origin of 'pa' - it's common in syntax extensions
<djcoin> hcarty: thanks for the link. And is 'pa' initial of something or ?
<hcarty> djcoin: It's one of the few OSP projects I've seen which continued beyond the initial summer.
<vbmithr> hcarty: ok, I’ll notify the author, it’s probably not normal :)
<hcarty> djcoin: Yes
<hcarty> And Float.(1 + 2) says "unbound module Float"... which I know worked last time I tried it :-)
<hcarty> vbmithr: I get the same error under OCaml 4.00.1 and the latest pa_do
<hcarty> flux: pa_do can/does/should do some magic there
<hcarty> vbmithr: I've used it a fair amount, although not recently

2012-10-09

<thelema> hcarty: yes, thank you for your contributions along this line. I don't plan on pulling bounded out of the incubator for at least a full release, so that it can encounter the community and still be reasonable to change the interface
<hcarty> thelema: BatBounded is getting close(r?) to a generally useful state. modulo_of_ord (maybe with a better name?) should be added and the Numeric pieces should be expanded.
<hcarty> braibant: It may or may not work... but it has the right words :-)
<hcarty> braibant: A search turned up https://github.com/mzp/websocket-ocaml

2012-10-08

<hcarty> Good night all
<hcarty> hongboz: Agreed :-)
<hcarty> Batteries does provide Core-like breaks in compatibility but they are optional (BatFoo.Exceptionless)
<hcarty> If the IO piece could be overcome then that would be Quite Nice.
<hcarty> Batteries keeps compatibility with almost everything except, as hongboz points out, IO.
<hcarty> wmeyer: Core breaks compatibility with stdlib all over the place, but there are reasons for the changes.
<hcarty> wmeyer: It would probably need to be asked with some context
<hcarty> hongboz: The same could be said for providing 100% stdlib compatibility :-) An extra module could be provided.
<hcarty> hongboz: But I'm not convinced that 100% compatibility is the first step, or even a necessary step. It would be a useful thing to have somewhere/somehow.
<hcarty> hongboz: I agree that there is more to do. If the IO pieces in Batteries can be replaced with stdlib-compatible pieces without losing functionality then that would be a nice thing to have.
<hongboz> hcarty: sorry if I am too harsh, but the community really needs a high quality standard library, batteries currently does not meet the goal yet, 100% compatbility is the first step :-)
<hcarty> Bug reports, patches and posts to the development mailing list would all be helpful if you're interested.
<hcarty> hongboz: For what it's worth, I'm glad you're looking at Batteries with such a critical eye.
<hcarty> For myself later or anyone else reading the logs: let module M = (val m : S with type t = s and type tt = ss) in ... is the correct syntax for what I was trying to do earlier. http://caml.inria.fr/pub/docs/manual-ocaml/manual021.html#toc81
<hcarty> hongboz: Which interaction?
<hcarty> a useful thing to have that is.
<hcarty> hongboz: All that said, documentation on how to move code to use Batteries would be a useful.
<hongboz> hcarty: yes, that's what I did
<hcarty> hongboz: You can also move over piece by piece - take only the modules/functions you want.
<hcarty> wmeyer: Not worth the risk of missing
<hcarty> hongboz: The same thing works in 'normal' module syntax, so I was surprised to find that it doesn't work when unpacking first class modules.
<wmeyer> hcarty: I think the HEAD of batteries is quite often updates; so i dont take risk of shooting it
<hcarty> hongboz: Regarding the first class module issue I brought up - I know that it doesn't compile. That's why I said 'Shoot' :-)
<hcarty> hongboz: I don't know. Enum came from extlib originally. I'm not sure why it was created in place of Stream.
<hcarty> hongboz: There is an ongoing discussion about the removal of clone
<hongboz> hcarty: I read the source of batEnum one or two years ago
<hcarty> hongboz: I don't think that's fair. BatEnum's actions are documented. You can use BatSeq (for example) if you want to avoid the side effects.
<hcarty> hongboz: And BatEnum is probably more exposed than it should be. It's a useful plumbing module but as you hint at, the mixture of side effects and laziness can be surprising at times.
<hcarty> hongboz: I agree that moving to Batteries requires some IO changes - I ran into that when switching.
<hongboz> hcarty: in my opinion, batteries is still at alpha stage
<hcarty> hongboz: It could be, but it would mean scrapping all of what exists in Batteries' implementation.
<hcarty> hongboz: Various printers
<hcarty> hongboz: Output to strings/buffers/etc.
<hcarty> hongboz: BatIO is tied to a lot of what Batteries provides. It could be removed but it would hurt the library significantly.
<wmeyer> hcarty: we tried to use Fan on my machine, and hongboz have some bootstrapping stuff that does rely on particular version of batteries or rather structure of the basic interfaces
<hcarty> hongboz: Is it a linking or installation issue?
<hcarty> Shoot. let module M = (val m : S with type t = s with type tt = ss) in ... doesn't work.
<hongboz> hcarty: believe me, I have tried to `open Batteries
<hcarty> hongboz: I disagree. Batteries does (did?) provide a compatibility layer for the stdlib.
<hcarty> wmeyer: 1.5 is pretty stable. 2.x is still in flux though.
<hcarty> hongboz: At a certain point it doesn't make sense to optimize Batteries for code which doesn't target it.
<hcarty> hongboz: The IO piece is one of the more useful/important parts of Batteries in my experience.
<hongboz> hcarty: I know it's pretty close, but when you switch to any non-trivial code base using batteries, 90% you will have a compile error
<hcarty> hongboz: Batteries is pretty close to that. Perhaps not 100%, but it's not far off in its default (open Batteries) state
<hcarty> thelema: The result has slightly more verbose general value generators but simpler common case generators (option and saturation results)
<hcarty> thelema: I am getting close to finishing another overhaul of BatBounded

2012-10-06

<wmeyer> hcarty: ok, thanks. So it's a planed feature?
<hcarty> wmeyer: If you're looking for a pretty-printed list
<hcarty> wmeyer: Similarly for Array and Enum
<hcarty> wmeyer: In Batteries' git master branch there is IO.Incubator.List.pp

2012-10-05

<hcarty> Other than some used byte on disk, lost CPU time, and whatever bugs may exist
<hcarty> adrien: You can download ocamlbrew and run it locally without suffering any ill effects :-)
<hcarty> adrien: And https://github.com/hcarty/ocamlbrew/blob/master/RECIPES.md for a list of example invocations
<hcarty> The file that's piped into bash downloads and calls ocamlbrew automatically
<hcarty> adrien: You can download it manually
<hcarty> adrien: That assumes you have libev installed to make Lwt happy... if not then there is an extra step to set an environment variable to limit what is installed by default.
<hcarty> adrien: The test is as simple as http://vpaste.net/k3hhw
<hcarty> adrien: Works here
<hcarty> adrien: I'll test that now...
<hcarty> s/chould/should/
<hcarty> adrien: You chould try ocamlbrew then :-) Just now updated to build OCaml 4.00.1 by default.

2012-09-28

<pippijn> hcarty: runtime cost in a script (that's compile time cost, I think)
<hcarty> thelema: The application of record dismbiguation to trunk looks interesting. I've been following the associated bug. I'll have to brew it and see how it works.
<hcarty> thelema: I'm very glad 'open Batteries' doesn't impose that kind of penalty though. That would be unpleasant.
<hcarty> thelema: open Batteries vs open Core.Std runtime cost - they may differ due to being unpacked vs packed. Or perhaps some cost associated with C stubs. Or initialization.

2012-09-27

<hcarty> flux: Perhaps Lwt_mmap didn't make the cut
<hcarty> flux: lwt-plus was apparently merged with Lwt
<flux> hcarty, maybe it's not part of the official lwt distribution.. "lwt-plus"
<hcarty> That's interesting. It's not in the main online Lwt documentation.
<hcarty> flux: Thanks :-)
<hcarty> flux: Do you have a pointer to Lwt_mmap?
<hcarty> Bigarrays would be helpful there
<flux> ansx_, and then yuo can have memory allocated outside the ocaml memory management, as hcarty says
<hcarty> ansx_: I think the Ancient module can take a value out of the GC's reach. It's more focused on large, on-disk storage though.
<hcarty> ansx_: There is a reference here - http://people.redhat.com/~rjones/hvcalls/
<hcarty> fasta: You could submit a bug report
<fasta> hcarty: The documentation for Sys.remove could be better. It says it removes a 'file', but a directory is also a file, yet it doesn't remove those.
<hcarty> fasta: The core stdlib modules are documented well
<fasta> hcarty: sure, but for new code, they could introduce a Directory module.
<hcarty> fasta: At this point I expect that there are backwards-compatibility reasons for the naming
<hcarty> fasta: Despite the name, it's not *nix, Cygwin only
<hcarty> fasta: Most (?) of the Unix module works under Windows as I understand
<fasta> hcarty: I suppose that would only work under e.g. Cygwin.
<fasta> hcarty: why would it work? Windows!=Unix.
<hcarty> fasta: If Unix.rmdir works under Windows then that's one way
<hcarty> ansx_: Or add the 'else ();' piece explicitly
<hcarty> ansx_: Wrap the if n mod 100 = 0 ... part in let () = ... in
<hcarty> ansx_: 'if' without 'else' implicitly adds an 'else' branch returning unit
<hcarty> ansx_: It's definitely surprising at first, but it's useful
<hcarty> Without annotation
<hcarty> OCaml is also the only language I know of where 'let add a b = a + b' will do the right thing
<hcarty> ansx_: OCaml doesn't have operator overloading
<hcarty> ansx_: They are there because an int is not the same as a float
<hcarty> ansx_: And -. and *. and /. for floating point infix operators
<hcarty> ansx_: You need to replace the + with +.
<hcarty> ansx_: Values are not automatically converted from one type to another for one
<hcarty> ansx_: Depending on where you are coming from OCaml (and its language relatives) take a bit of getting used to.
<hcarty> ansx_: More precisely, what are you trying to do that you are unable to do and/or don't understand?
<hcarty> ansx_: What are you trying to do?
<hcarty> thelema: The pp-patch/pull request goes into BatIO.Incubator. That seems like a safer option until a final layout and implementation is decided on.
* wmeyer says good bye to pippijn & hcarty :-)
<wmeyer> hcarty: 10:34 PM :)
<hcarty> It's 10:34 here, but perhaps a different 10:34
<wmeyer> hcarty: Great idea!
<wmeyer> hcarty: xstrp4 examples look nice, somewhat reminds me perl
<wmeyer> hcarty: it looks like a dirty hack :)
<hcarty> pippijn: A tool combining the features of camlidl + saffire would be quite a thing to have (binding code generation + type checking of bindings)
<hcarty> wmeyer: ciml won't quite compete with that :-)
<hcarty> wmeyer: Very limited! I've never taken the time to use it beyond compiling the included tests. But it's still interesting from a quick-and-dirty bindings perspective.
<wmeyer> hcarty: pippijn have full C ast
<wmeyer> hcarty: but you know this :-) I think pippijn is also amused
<wmeyer> hcarty: ciml is limited ;-) (from what I see)
<hcarty> pippijn: http://chadok.info/ciml/
<hcarty> pippijn: For OCaml + camlp4 + C, ciml is an interesting project. Not what you're talking about I don't think, but a pretty cool use of camlp4.
<hcarty> wmeyer: Original is here - http://projects.camlcity.org/projects/xstrp4.html
<hcarty> wmeyer: It's pretty nifty. My hacks are here - http://0ok.org/cgit/cgit.cgi/xstrp4/
<wmeyer> hcarty: I will look into xstrp4 thanks - I didn't even know about it :-)
<hcarty> That's my hope
<hcarty> thelema: If anything were done with ocaml-pretty + Batteries I was thinking it would be instead of something built on format, not in addition to.
<wmeyer> hcarty: Yes, but in general it's the right thing to do
<hcarty> wmeyer: Unfortunately it's built on camlp4 which seems to constantly rise and fall in popularity and soundness of future
<hcarty> or <:sql<select foo from table where date = ${date, d}>>
<hcarty> wmeyer: My hacks on xstrp4 allow for things like <<Interpolate here: ${foo_value, custom_foo_printer}>>
<wmeyer> hcarty: neeed to look at it
<hcarty> wmeyer: xstrp4's internals do something similar to what thelema suggested, although perhaps not as effcient
<wmeyer> hcarty: cool :) You know, the format strings can be parsed most of the time at compile time. So we either have static spec, which might be not a string but something more composable, or just use combinators for smaller amounts of code
<hcarty> wmeyer: And as hongboz mentioned, xstrp4 can do some nice things. I've done some hacking on xstrp4 to make it a bit more general and extensible.
<hcarty> wmeyer: Regarding printing + camlp4 - Batteries's pa_string syntax extension has some impressive printing capabilities.

2012-09-26

<hcarty> It may be worth adding an _oasis and sending a pull request. Another item for the code todo list.
<hcarty> thelema: It gives you a relatively simple way to pretty-print to and IO.output. That seemed like the main draw to me for inclusion.
<thelema> hcarty: that's quite simple,
<hcarty> Or maybe in addition to Format.
<hcarty> thelema: This may be small enough to consider instead of Format - https://github.com/toyvo/ocaml-pretty
<hcarty> Right
<hcarty> I'll start by only adding the BatIO.Foo.pp functions. The rest can be shuffled around separately.
<hcarty> I can probably get a pull request together this evening
<hcarty> thelema: Which approach do you think you will take? BatArray.pp or BatIO.Array.pp?
<hcarty> I had too many cuts. After taking them out the results are inline with what the toplevel prints.
<hcarty> Although that could have been due to some other issue in the code
<hcarty> I removed the flush from each because it was messing up indentation
<hcarty> And I think there was an unbalanced open/close box or few
<hcarty> gist improved again. Output is less ugly, but there is a leading newline in all of my tests.
<hcarty> Ideally. That's a sometimes painful shortcoming of ocamldoc.
<hcarty> ocamldoc would point point to the appropriate location, correct?