2008-05-02

<hcarty> That is a very nice introductory page
<Yoric[DT]> hcarty: I'll take a look.
<hcarty> It allows you to use git locally and feed changes back to an upstream Subversion repository
<hcarty> Yoric[DT]: If you have any interest in learning git between now and when you have your official git repo on the forge, git-svn seems to work fairly well
<hcarty> palomer: It was several hours ago that you asked, but you can '#use "foo.ml";;' from the OCaml repl

2008-05-01

<hcarty> My pleasure. I hope it ends up being informative/useful. It has minimal commenting as I just hacked it together as a test, but it will hopefully be usable. Ask if any of it doesn't make sense.
<struk_Atwork> hcarty, thanks! will try it when I leave the office and therefore make it back to linux land
<hcarty> struk_Atwork: http://0ok.org/code/ocaml/example-camlp4.tar.gz is an example using the extension I pasted earlier along with a few others. If you have OCaml 3.10.x then "ocamlbuild test.native" will build it
<struk_Atwork> hcarty, no idea what that is! should I be excited as well?
<hcarty> I am really looking forward to Fortress, but I imagine that is several years away from being ready for general consumption.
<struk_Atwork> hcarty, indeed. its pretty important to natural express the wealth of math formulae out there
<hcarty> But, as you said, being able to use (+) for matrices and other data structures is very appealing, particularly if you can keep OCaml's type inference in place
<struk_Atwork> hcarty, nope just heard of it today
<hcarty> And I use the toplevel a lot
<hcarty> struk_Atwork: Have you used a camlp4 extension before? I have not relied on them much because they can cause problems with OCaml 3.10.x+'s toplevel
<hcarty> The camlp4 syntax extension I linked earlier is meant to provide a subset of their final product because I read their proposal and thought "Cool!"
<hcarty> Likely with some extra library support as well.
<hcarty> Their project will be implemented using camlp4 (mostly, I think)
<struk_Atwork> hcarty, I'm not clear as to what the fundamental differences of their project and camlp4 is
<hcarty> struk_Atwork: The OSP project should be much more generally useful, but this does 70-80% of what I am looking for. I emailed the student and mentor to see if they have any further implementation details in place.
<struk_Atwork> hcarty, very cool stuff..just looked over your code and the camlp4 project
<hcarty> bluestorm: No, nothing yet. I did email them though.
<hcarty> struk_atwork2: http://ocaml.pastewith.us/71 -- I think this is the latest revision. I'll check against my local copy of the code.
<hcarty> bluestorm: Mine?
<struk_atwork2> hcarty, sure I'm interested.
<hcarty> Matrix.(a + b) to Matrix.add a b
<hcarty> struk_atwork2: I have a very very simple extension to the Float.() example on the camlp4 wiki if you are interested
<struk_atwork2> hcarty, OSP ? Ah yes the summer project. I know there is one...that's why I jokingly brought it up. I am actually hoping to be significant contributor to qtcaml
<hcarty> for OCaml, of course
<hcarty> struk_atwork2: There is an OSP to handle that situation
<hcarty> orbitz: Where are you going to grad school? The school and/or department may have something to help you out

2008-04-30

<hcarty> Though there are probably statically compiled darcs binaries that would work... that was what I used in the past, linked from the main darcs site
<hcarty> Someone who doesn't have root access to a CentOS 4 server
<hcarty> And the in-place-checkout seemed ridiculously cool
<hcarty> I picked up git instead because C and Perl are more common than GHC
<hcarty> I hope to get the time to check out darcs again now that v2 is out. Its command line interface is very nice.
<hcarty> I think they can both do that as well, though I don't know how the interfaces compare
<hcarty> They both have chunk-by-chunk commit, which was the killer darcs feature for me when I first learned of it
<hcarty> darcs has the benefit of fitting in to one binary, but the "git" wrapper hides the multitude of tools used by git
<hcarty> The recent versions of git seem to be pretty reasonable with respect to the quality of the interface
<psnively> hcarty: hm.
<hcarty> psnively: darcs and git seem pretty similar to me
<hcarty> I learned it recently and feel more alive than ever! Clearly, this is due to learning git.
<hcarty> "As I understand" - so I may be wrong
<hcarty> As I understand, darcs does not, by default, keep a clear history of when things happened. It's a strength in some cases, a weakness in others.
<hcarty> With the blessing of Xavier Leroy (and I suppose the rest of the core team)
<hcarty> Which is why Yoric[DT], thelema, bluestorm and others are working on a community distribution
<hcarty> The core devs don't want to add more to the basic OCaml distribution
<hcarty> Pcre is much nicer to use
<hcarty> I think all three of those have a fair amount of C code at their core
<hcarty> (speculation) Maybe because they rely more on C?
<bluestorm> hcarty: nothing really exciting : http://bluestorm.info/ocaml/numeric/numeric.mli.html
<hcarty> What is the "numeric stuff"? Sounds interesting
<hcarty> naufraghi: What is the problem you are having with this code?
<hcarty> Either "statement;" or "let () = ... in" if you are performing a side-effect only operation
<hcarty> naufraghi: In general, I would avoid using "let _ = ..." as it can cover up subtle errors
<hcarty> naufraghi: lots of printf statements, compile with debugging symbols, run with OCAMLRUNPARAM=b to get backtraces on uncaught exceptions...
<hcarty> bluestorm: I am crunching through 10 years of satellite data, so performance is something of an issue. And to my eyes, there is very little difference between the two methods... they are both clean and nicely type-inferenced.
<bluestorm> hcarty: i have to admit i never considered any other difference :p
<hcarty> bluestorm: Sorry, the grid elements were floats, not histograms
<hcarty> So for this case at least, the difference really does seem to come down to "do you need subtyping?" and what looks prettier.
<hcarty> The actions applied were the same in both cases.
<hcarty> bluestorm: re: our module vs class discussion yesterday: I did a test comparing a grid module with a grid class, with the grid elements made up of histograms. The difference turns out to be small-to-none, with the class implementation generally being very slightly quicker than the module implementation.
<Yoric[DT]> hcarty: well, I might do that, then.
<hcarty> s/as is/as they are/
<hcarty> Yoric[DT]: I second bluestorm's comments regarding using may_* for the option-returning functions and leaving the exception-throwing functions as is
<hcarty> RobertFischer: What sort of graphics?

2008-04-29

<bluestorm> hcarty: i think that functor registration make it possible to use those extensions with a custom lexer/parser
<hcarty> bluestorm: What is the difference? Does the functor registration make it easier to stack extensions?
<hcarty> Minus the trace function in c'
<hcarty> bluestorm: http://pastebin.be/10897 -- I think this is the class equivalent
<bluestorm> hcarty: http://pastebin.be/10896
<hcarty> The type inference may make that a non-issue
<hcarty> I may be making this more complicated than it needs to be
<hcarty> Perhaps? Can I restrict the 'a in 'a grid_t somehow in that case?
<hcarty> Functors + include seems to be the proper module-way, while classes + inherit seems to be the proper OO way
<hcarty> So a histogram grid_t, float grid_t, int grid_t, etc.
<hcarty> I have 'a grid_t (grid_t is a record with 'a array array and missing : 'a, among others) and I would like to create different types of grids, which allow different operations to be performed on them
<hcarty> I'm not sure which would be better for what I am doing
<hcarty> bluestorm: Well, for the snippet on the ocamldefun page, functors and classes seem to incur a similar run-time cost, and the scaling for basic (+) and (/) seems to be similar to what is shown in that table
<hcarty> I just wanted to check for others' experiences. The subject seems to come up every once in a while on the lists and no clear answers come out. Which probably means there is no clear answer.
<hcarty> I just git-branch'd to test functors... I expect and hope that any differences will be lost in the noise
<hcarty> bluestorm: No re:3%
<hcarty> bluestorm: Yes, and in this case I'm working with histogram array arrays so there may not be that much of a penalty
<hcarty> flux: I would think so. That's why I am reluctant to trust microbenchmarks on this.
<bluestorm> hcarty: the problem is with low-level optimization
<flux> hcarty, should depend on the code, no?
<hcarty> But I've also read that class method calls are (sometimes) cached, elminating their runtime penalty
<hcarty> I remember reading something from Xavier Leroy on the mailing list indicating that the penalty for using functors is/was on the order of 3%
<hcarty> Jason Hickey's chapter on functors seems to make the basics clear though
<hcarty> I'll give it a shot... I have used OCaml classes before, but not functors so this is partly an excuse to learn how to use them effectively and to have a direct comparison with OCaml OO
<bluestorm> hcarty: you could generate example code quite easily, using a function wich specialize on floats (eg. (<) )
<hcarty> Does anyone have any experience with or pointers to examples of the runtime performance of functors vs classes in OCaml?

2008-04-28

<hcarty> For example, lacaml provides a toplevel pretty-printer for matrices
<hcarty> mattam: You can write pretty-printers for different data type for the toplevel to use. They may be specific to the toplevel, though I am not certain.

2008-04-27

<hcarty> The commented parts being non-functional toying around
<hcarty> http://ocaml.pastewith.us/74 -- This is takes "private type t = int" and expands it in to an included module + signature. I'm trying to work through how to generate the name "t_of_int" to make a generating function.
<bluestorm> hcarty: camlp4 is a good way to learn about ocaml features you never used :-'
<hcarty> Wow, yes it is
<bluestorm> hcarty: you can try in your command line
<hcarty> I am trying to make a pa_private which does a transform similar to that discussed here: http://caml.inria.fr/pub/ml-archives/caml-list/2007/11/548712fc1b14955da573783c4d942c54.en.html
<hcarty> Ok
<bluestorm> hcarty: you know that <:foo< bar >> expressions expand to camlp4 AST terms ?
<hcarty> bluestorm: What do the parts of "Ast.TyDcl _loc n tpl tk cl" mean from pa_private.ml? Or do you have a pointer to where I could find this my self?
<hcarty> And if it ends up being useful for someone else the so much the better
<hcarty> Yes, I am not sure how much time I should put in to this given the similar OSP. It is something of an interesting learning experience though.
<hcarty> I think a Float module would be the way to go - my only concern would be speed. I don't know if it slows things down at all to use Float.add rather than (+.)...
<bluestorm> hcarty: on another topic, i think it would be better on the long run to delete the Float-specific part, and to attach a runtime Float module that would provide the needed functionality
<hcarty> That's what I thought
<hcarty> Is it possible to match something like '( or `( rather than using ( (); ... ?
<hcarty> bluestorm: Hacks are welcome - the array patch does its job from what I can tell
<hcarty> Ack, that is an awkward sentence
<hcarty> s/I guess/it seems/
<hcarty> <:expr< Int.($e$) >> -> <:expr< $e$ >> -- the simple minded match approach does not work, which I suppose should be obvious I guess because the transform seems to be recursive
<hcarty> bluestorm: No, I did not. Though to be honest I don't know how :-)
<bluestorm> hcarty: did you disable transformations inside nested Foo.( ... ) ?
<bluestorm> hcarty: you could allow x.(Int.(0))
<hcarty> palomer: The general rule thrown around is that if you have to ask, you shouldn't use it
<bluestorm> hcarty: :p
<hcarty> bluestorm: Drat, a problem with the new pa_float : Float.( 1 + x.(0) ) --> (1. +. x.(0.))
<hcarty> palomer: I don't think so. You can use dark magic (Obj.magic) to do tricky things, though it is generally considered a very bad idea. Why do you want to?
<hcarty> I emailed the student and metor for the Delimited Overloading project and updated the Camlp4 wiki with my changes to the pa_float code
<hcarty> I was wrong - it does not seem to happen with 3.09.2, at least not with a very minimal OCaml install on Etch
<hcarty> I can't be certain as I don't have access to camlp4 < 3.10. But I am fairly certain I had the problem with 3.09.x. I just assumed it was my fault since I was very new to OCaml at that point.
<hcarty> It was around in 3.09.x as well I think
<hcarty> I am hoping that it will be fixed before 3.11, but I wouldn't know where to start to provide a bug fix
<hcarty> bluestorm: I do not. http://caml.inria.fr/mantis/view.php?id=4495 -- It is marked acknowledged but has not changed since
<bluestorm> hcarty: do you know a reason the bug wasn't corrected yet ?
<hcarty> I think I will - even if they use a different method, I would like to keep the two consisten so I can swap theirs in when/if it is all finished
<hcarty> Two #use toplevel commands give "I/O error: Bad file descriptor" when camlp4 is in use
<hcarty> Does not seem to be, either in 3.10.1 or 3.11 CVS
<hcarty> I was thinking of the #use bug when camlp4 extensions are loaded
<hcarty> With the side effect of making the code more concise and easier to follow in many places
<hcarty> bluestorm: Thanks for your help, and your extensions - now I can obfuscate my code, add another point of failure with respect to syntax changes and breaking loading my code in the toplevel :-)
<hcarty> bluestorm: Ah, I figured it out... I had <:expr< ( +. ) >> -> <:expr< $uid:m$.add_float >>
<hcarty> Huh. Maybe I changed something else without realizing it.
<hcarty> With a few additional operators in the extension - ( *: ) matches to Foo.mul_scalar
<hcarty> Matrix.( mat1 + mat2 *: Float.(1 + 1) ) --> Matrix.add mat1 (Matrix.mul_scalar mat2 (Matrix.add_float 1. 1.))
<hcarty> That's what camlp4o prints
<hcarty> If I do, the inner Float.( ... ) contents would use Matrix.add rather than Float.add (or +. in this case)
<hcarty> But I want to be able to nest Module.( ... ) constructs. Something like: Matrix.( m1 + m2 +: Float.(1 + 2) )
<hcarty> I am not sure if that is the right way to ask that question...
<hcarty> bluestorm: How would I write 'm = UIDENT; "."; "("; e = SELF; ")"' in an <:expr< $uid:mm$.($expr:e$) >> like way in an Ast.map class?
<hcarty> Very cool
<hcarty> bluestorm: Ok, thanks
<hcarty> bluestorm: Is (\ \1 +. x) equivalent to (fun v -> v +. x) when using pa_holes?
<hcarty> Ah yes... I would have been much more reluctant to try this if that was my starting point.
<bluestorm> hcarty: i was thinking of the original implementation, http://martin.jambon.free.fr/extend-ocaml-syntax.html#replacing
<hcarty> It is based on the http://brion.inria.fr/gallium/index.php/Pa_float - I had to make the changes at the bottom of the page to get that original version to compile and function for me
<hcarty> Not something that will compete with the OSP project, but a working hack of an existing camlp4 extension at least
<hcarty> bluestorm: http://ocaml.pastewith.us/71 -- A working but very simple-minded version of a general pa_float extension
<hcarty> "My OCaml programmer beat up your Haskell programmer"
<hcarty> Nevermind, it was a simple change... m = UIDENT in place of "Float"
<hcarty> But I want to play with it now ... and the SoC project looks much deeper
<hcarty> It is!
<bluestorm> hcarty: is that not a Summer of Code project ? :p
<hcarty> The idea being to, eventually, have this work for Float.(...) or Matrix.(...) or ...
<hcarty> http://ocaml.pastewith.us/68 -- I am taking a very naive stab at generalizing the pa_float extension. How would I get the "Float" module name automatically, without hard-coding it?
<hcarty> Using the code on that page, compiled using the command listed on that page, gives errors: http://ocaml.pastewith.us/67
<hcarty> Does pa_float (http://brion.inria.fr/gallium/index.php/Pa_float) work for anyone here?

2008-04-26

<hcarty> bluestorm wrote a camlp4 extension
<hcarty> Particularly if associativity could be set per-operator. I don't know how reasonable that would be.
<hcarty> pa_infix maybe
<bluestorm> hcarty: interesting
<hcarty> If Ciml (http://friggeri.net/blog/2008/02/26/ciml-c-in-ocaml) developed to handle more advanced types then it may be worth including
<hcarty> flux: Yes, I was just about to ask :-)
<flux> hcarty, ah, my msg must've appeared strange, as I was actually looking at this: http://nleyten.com/2008/04/24/oh-the-humanity.aspx
<flux> hcarty, cool, finally ocaml's error messages can compete with c++ (and maybe haskell when certain extensions have been used?)
<hcarty> Regarding pa_private - this list post seems to suggest a good syntax mapping, but I don't know how easy or difficult it would be to implement
<hcarty> bluestorm: I would think the second
<hcarty> bluestorm: Your pa_holes.ml extension may be worth including
<hcarty> s/speaking/acting/
<hcarty> The thread did not clear up the reason for this feature for me. But that could be an allergy-induced haze speaking
<hcarty> "didn't seem to go anywhere" is wrong

2008-04-25

<hcarty> There was a mailing list thread discussing it, but it didn't seem to go anywhere
<hcarty> I am sure they did
<hcarty> The only difference I can see between that and the same abstract type is that the toplevel shows you values of T.t without any extra work
<hcarty> Yes
<hcarty> module Foo : sig type t = private int val make : int -> t end = struct let make x = x end;;
<hcarty> Sorry, that's in the signature
<hcarty> type t = private int
<hcarty> What is the point of private abbreviation types in OCaml 3.11, vs simply using abstract types?
<hcarty> ocamlbrowser is a nice GUI tool for such things if you don't want a browser window open
<bluestorm> hcarty: as far as i know, no marshalling solution can marshall all the ocaml values
<hcarty> I have used YAML for storing data when working in Perl, but I haven't done any non-binary data storage in OCaml
<hcarty> What are the relative benefits of sexplib vs json_static?
<hcarty> If you have something working now though then it may not be worth the restructuring effort if this is not a long term project
<hcarty> You may be able to use lacaml with them directly, though I am not sure
<alexyk> hcarty: ah, yes -- but SVD is a very specific task with Fortran open source for decades
<hcarty> lapack wrapped for OCaml
<alexyk> hcarty: what's lacaml?
<hcarty> Could you use lacaml?
<alexyk> hcarty: Netflix prize!
<hcarty> alexyk: What sort of program?
<alexyk> hcarty: amazing to see how OpenMP loads them all... 800% on an 8 core box in top
<hcarty> But this also means I only use 1 of the two processors I have available on my main number crunching system
<hcarty> alexyk: Thankfully I haven't run in to speed constraints which OCaml + a bit of C can't handle
<alexyk> hcarty: I use Fortran with OpenMP for speed
<hcarty> I still use a lot of long names with OCaml
<hcarty> And OCaml has me quite sold on functional programming for everything except where it's easier not to
<hcarty> I haven't used Ada - it looks like it could be very nice, but also seems rather verbose
<hcarty> Bigarray can do something similar with subs and slices
<hcarty> I haven't used Pascal in 10 or 15 years...
<hcarty> s/mean/mean by/
<hcarty> alexyk: What do you mean a "an effective length below maximum"?
<hcarty> Sounds relatively close
<hcarty> bluestorm: I think I understand the intent, but I would have to think about it for a bit to come up with an equivalent expression
<bluestorm> hcarty: it's the idea of someone using ridiculously naive/simple/easy tools among other people playing on a much larger scale
<qwr> hcarty: obviously the library was written by noobs ;)
<hcarty> bluestorm: I don't know French - what does that translate to, roughly, and what is the intended meaning?
<hcarty> Even thought Array.iter IS a for loop!
<hcarty> Yep, I knew someone had to shoot that down :-)
<bluestorm> hcarty: noob :-'
<hcarty> Or use a for loop
<hcarty> bluestorm: That's my bigger concern, honestly :-) I don't want to have to unwrap everything from an 'a option. But more experienced folks than I claim it is ok with the right library support.
<bluestorm> hcarty: you'll have to choose between an additionnal "_exn" and a heavy 'a option handling, so be happy with only 4 more chars :-'
<hcarty> The OO syntax extension, or a subset of it, may be worth including in the list
<Yoric[DT]> hcarty: :)
<hcarty> Yoric[DT]: Makes sense, though I cringe a little at the ugly extra 4 characters to type :-)
<Yoric[DT]> hcarty: it's more along the lines of marking clearly exceptions than completely removing them.
<hcarty> Yoric[DT]: What is the reason for moving away from exceptions?
<hcarty> A few people have put some work in to UInt32 and UInt64 modules though, I think
<hcarty> damg: Only when using the Bigarray module. And even then it is only the storage which is unsigned - you still interact with the Bigarray fields using signed integers

2008-04-24

<hcarty> string_of_int
<hcarty> make and create seem to both be used throughout the stdlib
<hcarty> I always have to look up which of those is deprecated...
<hcarty> palomer_: Array.make perhaps?
<hcarty> yziquel: I don't know if it works with .cmo files, but ocamlbrowser provides a GUI for browsing OCaml interfaces. It may do what you want.
<petchema> hcarty: type 'a foo_t = { contents : 'a array } is a parametric type
<hcarty> The GUI tools for git are very nice as well (git-gui and gitk)
<hcarty> No need to create separate directories for new branches
<hcarty> I really like the in-place checkouts in git
<hcarty> Yoric[DT]: I really enjoy git. darcs as well, but git a bit more
<hcarty> Both the OO and Polymap extensions seem very nice though
<hcarty> Oh, how I would love to... but camlp4 breaks #use in the toplevel, so I tend to avoid it when developing new code
<bluestorm> hcarty: then use pa_openin :]
<hcarty> My concern came mainly from having segements of code like a.Foo.field.Bar.other
<hcarty> It also provided an excuse to learn something about how to use OCaml classes and how they work
<hcarty> Record name collisions are part of why I did my initial implementation of this code using classes.
<hcarty> The actual type is more along the lines of : { grid_contents : 'a array array ; missing : 'a ; resolution : float ; ... }
<hcarty> bluestorm: Very good point...
<bluestorm> hcarty: incidentally, { contents : ... } is used by the "ref" type
* Yoric[DT] agrees with hcarty.
<hcarty> tsuyoshi: Ok, thank you.
<hcarty> What is the name for a type like: type 'a foo_t = { contents : 'a array } ? Is this a phantom type? I am unsure of the terminology

2008-04-22

<hcarty> vpsvillage.com is decent and cheap from my limited experience with them
<hcarty> I think CAMLreturn has to come at the end of a function, but I may be wrong about that
<hcarty> kig: Not sure, you may want to look at the caml_failwith source to find out

2008-04-21

<hcarty> I think there is already a simple Dr. Scheme plugin for OCaml. Hopefully it will be made to work with EasyOcaml as well.
<hcarty> That's a big plus for ocamlp3l, since it is really just a few libraries on top of vanilla OCaml
<hcarty> JoCaml on the other hand does seem to work quite nicely. It's just too bad that it is separate from mainline OCaml.
<hcarty> I have been unable to get any examples to run using the parallel implementation, only sequential and graphical
<delamarche> hcarty: It's still very much a prototype, but I liked it
<hcarty> delamarche: Did you have any success with ocamlp3l?

2008-04-17

<hcarty> It may be an journal-on-ramdisk issue though. I've requested that it be changed to ext2 as a test.
<hcarty> And the program which seems to do the corruption is running as a non-root user
<hcarty> At this point, I just want to know how it is being corrupted. It seems very strange.
<hcarty> I'm not the admin on the system, but I would guess habit
<hcarty> Nope, all access is through the appropriate mount point.
<hcarty> /dev/ram allocated with ~550Mbytes and formatted to ext3
<hcarty> It also corrupts a ramdisk, which seems disturbing to me. But perhaps ramdisk ram isn't protected.
<hcarty> petchema: I'm trying that now. It's taking a while due to the large amount of stuff shuffling around in ram.
<hcarty> I have never had this problem before in any language, so I'm not sure where to start
<hcarty> The programs in question are written in OCaml, but use several C libaries. There is a memory leak somewhere, but to make matters worse the memory is not freed when the program exits.
<hcarty> Any suggestions on where to look when a program leaks memory that is not freed after the program exits?

2008-04-16

<hcarty> Preston: What OS are you using?
<hcarty> Glad to be able to help. Tuareg is why I started using Emacs, and the main reason I continue to do so.
<hcarty> http://ocaml.pastewith.us/65 -- This is pieced together from things I have found all over, so it is quite messy
<hcarty> Sure.
<hcarty> My emacs knowledge is very minimal though, so I have no idea if there is a better place to put it
<hcarty> '(tuareg-in-indent 0) is inside my (custom-set-variables ...) section
<hcarty> Just the indent-after-in
<hcarty> I disabled that as well..
<hcarty> Ah yes
<hcarty> Which part(s)?
<hcarty> Comments seem to be the worst offenders in messing up the highlighting
<hcarty> You are welcome
<hcarty> (define-key global-map (read-kbd-macro "C-x C-x") 'font-lock-fontify-buffer)
<hcarty> One moment..
<hcarty> I ended up binding ctrl-x-x (whatever that is in emacs-speak) to "fix the highlighting, dammit"
<hcarty> orbitz: It loses highlighting sometimes...

2008-04-15

<kAworu> hcarty> yup i just found it in the ocaml-doc thanks .)
<hcarty> kAworu: ocamlc graphics.cma foo.ml
<kAworu> hcarty> thx. could you give me the ocamlc option that i need i read the man ocamlc but didn't found it.
<hcarty> kAworu: It sounds like you are not linking in graphics.cm(x)a
<hcarty> And they both seem like they are unmaintained
<hcarty> coThreads and ocamlp3l both seem promising. Sadly, the process/parallel ocamlp3l runtime has not worked in my limited testing.
<hcarty> Hopefully most of them will work out well and be maintained. Most of the projects from last year seem to have been unmaintained since the OSP ended.
<hcarty> Wow, those look like some ambitious projects this year
<Smerdyakov> hcarty, yes. I plan to write a textbook on implementing certified compilers with Coq, at least.
<hcarty> As you mentioned, there is little to no documentation for general purpose programming. Do you think that will change?
<hcarty> It is written in OCaml, so perhaps OCaml libraries could be used with some effort
<Smerdyakov> hcarty, it already is a reasonable language to develop general purpose programs in.
<hcarty> Smerdyakov: Do you think Coq will develop enough real-world support to become a reasonable language to develop general purpose programs in?
<hcarty> Yes, being able to write a function that takes any_class with #foo_method and have it type checked for you is quite nice
<thelema> hcarty: see above

2008-04-14

<hcarty> jonafan: Could you use Pcre rather than Str? It may handle large splits better than Str