<hcarty>
Alpounet: I got a go-ahead from Chris King for FrGui, so I'll hopefully get to take a look at that in more depth over the coming weeks
<hcarty>
I'm most interested in the GUI portion - the backend doesn't matter as much to me as long as the interface is fairly clean.
<hcarty>
:-)
<hcarty>
psnively: Yes, I've seen those on the list. I just got a reply from Chris and he linked to each of those as well :-)
<hcarty>
I'll ask his (Chris) opinion regarding which version of the library would be better suited for future development
<hcarty>
Alpounet: If Chris King is not planning to continue maintenance of FrGui and is ok with someone else continuing it then I will start it up under newhope
<hcarty>
kaustuv: Do you mind if I Cc: you on an email to the current author of the Cairo bindings?
<hcarty>
The OSP version works without a syntax extension. I'm not sure which is more complete or the better one to pick up.
<hcarty>
Yoric[DT]: Oh, cool. Thanks, I'll take a look.
<hcarty>
It seems unmaintained since the 2007 OSP
<hcarty>
Does anyone know Chris King's contact information? I think the FrGui library would make a nice project for newhope.
<hcarty>
kaustuv: I'm chatting with some folks in #cairo now about getting everything finalized for an official git repository to continue the OCaml binding upkeep
<hcarty>
Is that all part of your work on OPA? Or multiple projects?
<hcarty>
I'm doing well, thanks. Glad to hear that you like the job.
<hcarty>
Yoric[DT]: How is the new job?
<hcarty>
Hello
<hcarty>
kaustuv: It still needs a proper GODI install, but from what I understand you can do anything from the command line that you can do from godi_console
<hcarty>
kaustuv: It does
2009-06-11
<hcarty>
kaustuv: What is the current state of your cairo-ocaml modifications?
<hcarty>
kaustuv: Far too cheeky. "Von Neumann computers with a C compiler or network interface" is much more appropriate.
2009-06-10
<hcarty>
travisbrady_: GODI requires a Makefile, so it may be for that reason
2009-06-08
<_andre>
hcarty: thanks. there's only this ocaml version installed, and i have the dependencies on README
<hcarty>
_andre: If you don't have any further luck, I'd recommend a post to the mailing list
<hcarty>
I'm not sure beyond that. Perhaps extNetChannels.ml was changed separately from extNetChannels.mli (if it exists)
<hcarty>
Perhaps a missing dependency? Or multiple versions of OCaml installed on your system?
<hcarty>
Are you using system OCaml (non-Batteries) packages (Debian/Fedora/etc), GODI or building from scratch?
<_andre>
hcarty: ocaml 3.11.0
<hcarty>
_andre: I have not. What version of OCaml? Is this a clean checkout?
<hcarty>
Yoric[DT]: And thank you for pushing the Exceptionless modules - I fought using them at first, but the resulting compile-time checks have made me a happier person :-)
<hcarty>
Yoric[DT]: I think it is important to keep Batteries as forward-looking as possible. It has done a pretty good job of that so far, from what I can tell.
* Yoric[DT]
agrees with hcarty.
<hcarty>
flux: But I think that, or simple requiring an extra "open" line in legacy/pre-Batteries code, would be a good way to go
<hcarty>
flux: I don't think a compat-module exists yet
<hcarty>
It would lose some of the ease of use when incorporating Batteries in to a new project
<hcarty>
But I do not think it would be a good default
<hcarty>
Yoric[DT]: I think that a backwards compatible option (ex. "open Batteries_stdlib_compat") is a wonderful idea to avoid problems from changed exceptions
<hcarty>
Yoric[DT]: thelema posted to the Batteries mailing list with a suggestion to make a backwards-compatible Batteries the default case when compiling with Batteries
<hcarty>
thelema: What is the reasoning for having Batteries in backwards-compatible form (exceptions, module signatures) by default?
<hcarty>
It was apparently broken by a fix to another bug
<hcarty>
kaustuv: I think there was a recent update in the bug tracker saying that this is/will be fixed for 3.11.1
2009-06-06
<hcarty>
I haven't used 3.10.x in a little while though so I'm not certain about that.
<hcarty>
The INSTALL or README file in the base directory should have some information on using the ocamlbuild-based build for OCaml
<hcarty>
ocamlbuild is an OCaml-based build system included with OCaml versions since 3.10.0
<hcarty>
pipping: Would you be willing to file a bug report about this with your changes?
<hcarty>
pipping: You could try the ocamlbuild compilation method. It would likely require hacking some of the build files as well, but perhaps its parallel build support would do a better job.
<hcarty>
It would be a nice thing to have working
<hcarty>
pipping: I have not tried "make -j n" with the OCaml sources... you could check the Changelog to see if there is any information there
<hcarty>
pipping: Not that I know of. Are you using the OCaml source files directly from INRIA? And what OS?
2009-06-04
<hcarty>
Slower: Have fun learning the language
<hcarty>
I'm off for the night
<hcarty>
But yes, the "catch all" match is "| _ -> ..."
<hcarty>
Slower: You might want to put these in a pastebin
<hcarty>
There are a number of concurrency and parallelism libraries floating around for OCaml, so such items are not completely out of reach.
<hcarty>
It's well worth learning, though this room is somewhat biased on that topic...
<hcarty>
Practical OCaml has received less than stellar reviews from inside the community. I have not read it personally though.
<hcarty>
wabash: It's a pretty darn nifty language :-)
<hcarty>
The toplevel/REPL is commonly used in OCaml, though programs are likely at least as common
<hcarty>
OCaml can be compiled to either bytecode or native code, and the results tend to be fairly fast
<hcarty>
Integral?
<hcarty>
wabash: Yes
2009-05-25
<hcarty>
mrvn: A string would likely be faster, unless you drop to C. And in that case I don't know which would be faster.
<hcarty>
mrvn: Is writing some C acceptable? And is that one huge bitfield, or several in one structure?
<mrvn>
hcarty: ~320000 bits
<hcarty>
mrvn: How wide should your bitfield be? You could use an int8_unsigned Bigarray, avoiding any char <-> int casts. Strings may still be faster though.
2009-05-21
<hcarty>
travisbrady_: Batteries also has a module Print which provides user-defined printf augmentations. There are other libraries and syntax extensions which can generate automatic printers.
<travisbrady_>
hcarty: ahh, ok, thank you
<hcarty>
travisbrady_: I think Batteries has a function called "dump" or similar which does this
<hcarty>
travisbrady_: OCaml doesn't not keep type information around after compilation, so without extra code you are restricted to printing the data representation
<hcarty>
Some camlp4 magic could probably clean it up as well.
<hcarty>
mrvn: Indeed
<hcarty>
mrvn: No, that's an array with 1230 elements as I understand it
<mrvn>
hcarty: that is 4 dimensions, each one size 10 except the last.
<hcarty>
let d1230 = dec d1 d2 d3 d0 dim;; for example
<hcarty>
mrvn: I haven't toyed with it in a while, but according to the message and from what I remember testing it, you can stack them
<hcarty>
monadic_kid: I'm just the messenger :-)
<hcarty>
mrvn: I don't think so. It is stackable
<mrvn>
hcarty: that example is limited to arrays of size 10
<monadic_kid>
hcarty: i know what phantom types. You can do the same thing bit more nicer with type classes and functional dependencies (and better with associated types). This is just basically emulating dependant type system, kind of like expression templates
<hcarty>
mrvn: It's rather ugly, but the that posting has code to do it
<mrvn>
hcarty: one can do that?
<hcarty>
monadic_kid: That provides type-checked array dimensions
<hcarty>
monadic_kid: I'll try to find the mailing list posting
<monadic_kid>
hcarty:but was that what you was talking about?
<hcarty>
monadic_kid: Just saying that a similar technique could probably be adapted for lists
<hcarty>
monadic_kid: I don't have a particular need for that
<monadic_kid>
hcarty: you want to know the size of list at compile-time?
<monadic_kid>
hcarty: with dependant types yes
<hcarty>
There is fixed-size array code floating around somewhere, with the size encoded in the type. I imagine something similar could be done with a list.
<travisbrady_>
kig, hcarty: thanks, looks like i've got some downloading to do
<hcarty>
travisbrady_: Batteries is another library well worth using
<hcarty>
I've found its examples clearer than most
<Camarade_Tux>
hcarty, \o/ <-- sinking this time :)
<hcarty>
Camarade_Tux: Cheering or sinking?
<hcarty>
I'm looking forward to ocamlgir-based Clutter bindings - I'm curious to see how easy the toolkit is to work with.
<hcarty>
Camarade_Tux: It really is a nice tool for small to medium projects... probably easier than either omake or ocamlbuild for something that involves C
2009-05-19
<hcarty>
thelema: All of the "git-foo" commands were deprecated a few releases ago, to be replaced by "git foo" instead. They apparently still exist, just outside of $PATH
<hcarty>
Camarade_Tux: I had thought so too! Findlib-the-module support in ocamlbuild would be a really nice thing to have in the future
<Camarade_Tux>
hcarty, right : findlib.cmx?a
<hcarty>
Camarade_Tux: I started on a CPAN-like tool a while ago based around Findlib, but was unable to dedicate enough time to it to get it off of the ground.
<hcarty>
Camarade_Tux: Yes, there is a Findlib module
<hcarty>
robocop: You're welcome. Functors are powerful but can be a little strange to get used to.
<hcarty>
palomer_: From the output of "ocamlfind -list" I would guess it is findlib
<hcarty>
robocop: It is sort of a module that returns a module... functions for modules, perhaps. The manual has a decent explanation.
<hcarty>
robocop: In the case of Map, it allows the user to provide a type and a comparison function so that it is usable across any data type
<hcarty>
robocop: The stdlib Map is a functor
<hcarty>
palomer_: The Findlib module probably has something to do what you want
<Camarade_Tux>
hcarty, haha, but it probably won't get much more ;)
<hcarty>
Camarade_Tux: It sounds like ocaml-gir is shaping up nicely. The fact that it gets anything from a non-Gtk lib is rather promising.
<Camarade_Tux>
hcarty, with ocaml-gir, I could actually bind some of cairo but it would be very limited (only one function and a few types)
2009-05-17
<gildor>
hcarty: I will prepare a better version maybe for next year OCaml Meeting ;-)
<gildor>
hcarty: but now I have a little bit more time and know what I can really disclose
<gildor>
hcarty: yes, but at the time writing it, I was a little bit buzzy and concerned not to disclose various techniques I applied to one of my client project
<hcarty>
gildor: An expanded version of the OCaml as fast as C material with examples and explanation would be wonderful. Perhaps worthy of a project on the forge? :)
2009-05-15
<hcarty>
All three seem to be fairly widely used though. make has both OCamlMakefile and autoconf macros to ease its use. ocamlbuild has gained a lot of use since its introduction. And omake's users seem to really like it.
<hcarty>
AxleLonghorn: make is likely the most popular since at least a thin Makefile wrapper is required by godi
<hcarty>
robocop: The makefile is just a wrapper around ocamlbuild calls
<robocop>
hcarty: they use a makefil, no ?
<hcarty>
It has a rather significant ocamlbuild + ocamldoc setup from what I've heard
<hcarty>
robocop: It's not a simple example, but you could look at Batteries
<hcarty>
Not a problem, concentrate away :-)
<hcarty>
"let f (x : int) = x + 1" for example
<hcarty>
Is the intent to deliver these without needing the user to intervene? I can't think of the proper term right now...drat.
<hcarty>
Further spoiling is quite welcome
<hcarty>
Yoric[DT]: Are the implications of "further" something one who is not formally trained in CS would reasonably understand?
<hcarty>
OCaml has certainly spoiled me when it comes to type inference
<hcarty>
Yoric[DT]: Ah, that sounds much more interesting
<hcarty>
wmealing_: Someone mentioned Yeti yesterday, and it looks rather interesting - http://mth.github.com/yeti/
2009-05-14
<palomer>
hcarty, ill check if sexplib is object friendly in a sec
<hcarty>
jli: And OCaml for Scientists has received a lot of very positive reviews, but Mr. Harrop has... a reputation as m3ga pointed out :-) And it is a rather expensive book.
<hcarty>
jli: Regarding accessing records defined in a module - if the record type is defined in module Foo, you can do x.Foo.label if you want to avoid using "open Foo"
<jli>
hcarty: ah, thanks. it works now.
<Alpounet>
hcarty, AFAIK, such libraries do not use objects, since that's not OCaml's main "view of programming"
<hcarty>
palomer: Do you know if any of the downstream extensions/libraries (Sexplib, Binprot) are object friendly?
<hcarty>
palomer: Jane St. does not apparently use the OCaml object system, so that seems like a reasonable possibility
<hcarty>
It looks like the original paste made it as far as it did due to a previous definition of "type 'a dbl_list"
<hcarty>
Ariens_Hyperion: Change the second "type" to "and"
<hcarty>
jli: If you redefine types with the same name in the toplevel this sort of strange error can happen
<hcarty>
jli: Are you getting this in the toplevel?
<hcarty>
jli: You are quite welcome
<jli>
hcarty: okay, thank you
<hcarty>
jli: "| Cons record as cons" would save a bit of time computationally. It may be a bit more idiomatic as well.
<hcarty>
Yoric[DT]: Hello
2009-05-13
<hcarty>
jeff_s_: Ah, wow. That definitely sounds tough to track down.
<jeff_s_>
hcarty - sorry ya I can make one
<hcarty>
jeff_s_: Do you have an example of that problem? I'm curious to know what it looks like in case I run in to it. I would have thought that the compiler would spit out an error if the function is called before it is defined.
<hcarty>
gildor: While I agree with Alpounet that effort would likely have been better spent improving an existing plotting library than writing a new one, C. Troestler's participation does give the project an extra boost of promise
2009-05-12
<chahibi>
hcarty, so the pointers were still quite vague
<chahibi>
hcarty, I had to read what statements are and what expressions are
<hcarty>
chahibi: And the questions illustrated misunderstanding of areas outside of the question itself.
<chahibi>
hcarty, I searched (read where begin .. end was defined, and where let was defined)
<chahibi>
hcarty, it depends on the person
<hcarty>
chahibi: But you continued to ask after being told "your questions are answered here."
<hcarty>
chahibi: No, I sincerely hope that they won't be ignored.
<chahibi>
hcarty, how can you assume that
<chahibi>
hcarty, are you sure they are going to be ignored?
<hcarty>
chahibi: But why keep asking if the answers are going to be ignored?
<chahibi>
hcarty,* you can ask ignoring the answer, there is no contradiction
<hcarty>
chahibi: RTFM may be useless, but RthisFM is generally not.
<palomer>
hcarty, "follow these tutorials and you'll understand your the answer to your small question" can be quite discouraging
<hcarty>
chahibi: I don't understand what you mean.
<hcarty>
palomer: However, some effort should be made by the user to follow advice from others.
<chahibi>
hcarty, when can ask ignoring the answer, there is no contradiction
<hcarty>
palomer: I agree that "baby speak" should be as acceptable in OCaml (and #ocaml) as it is in the Perl community
<hcarty>
palomer: It's about ignoring the answers
<hcarty>
palomer: It's not about asking questions
<hcarty>
palomer: Interaction with other humans is important at times as well (otherwise why have #ocaml?), but search will generally find the answer rather quickly in a digital source.
<hcarty>
palomer: I do often quite often.
<palomer>
hcarty, try asking a question to a tutorial
<hcarty>
chahibi: No, which is why several people here suggested "THE right tutorial" to you.
<chahibi>
hcarty, should you really assume that people should know THE right tutorial? Really?
<hcarty>
palomer: I agree. But Hickey's book is less so, and Harrop's tutorial is VERY simple and direct.
<palomer>
hcarty, the documentation can be hard for a beginner
<hcarty>
palomer: That may be true, but sometimes the best "people" to ask are the documentation.
<hcarty>
chahibi: begin .. end is something which would be covered in a good tutorial. And rules of scope seem to be fairly consistent across most commonly used languages.
<chahibi>
hcarty, I don't usually use begin .. end in my code
<chahibi>
hcarty, and I asked just out of curiosity about begin ... end
<chahibi>
hcarty, and was in no way confronted to know that
<chahibi>
hcarty, my mistakes was that I supposed let a = 5;; is an expression, which wasn't
<chahibi>
hcarty, and quickly!
<chahibi>
hcarty, as well as a implementing operation on polynoms as lists
<chahibi>
hcarty, and their thread balancement
<chahibi>
hcarty, like threads
<chahibi>
hcarty, I read a manual, and solved many exercices
<chahibi>
hcarty, I am not completely getting started
<hcarty>
chahibi: But when the question is about getting started in the language, the tutorials will do a better job than just about anyone here has time to.
<hcarty>
chahibi: Lots of syntax and alogithm questions are asked and answered here
<hcarty>
chahibi: What is so odd about being told "Your question is answered in any of these tutorials"?
<hcarty>
palomer: The tutorials are, for some purposes, lacking. But there isn't a lot of point to walking someone through the basics of the language over IRC when there are existing sources which do it better.
<hcarty>
chahibi: Smerdyakov's suggestions are both better for really learning the language though.
<hcarty>
chahibi: Why not take the 10-60 minutes required to read a tutorial?
<hcarty>
chahibi: As many others have said, you will be much better served by reading one of the mentioned tutorials
<jli>
hcarty: right, I was just making sure.
<hcarty>
jli: Otherwise, how would you tell the difference between (let foo = "something") and (let foo () = "something")
<hcarty>
jli: The unit argument allows you to differentiate between a constant value and a function
<Alpounet>
hcarty, moreover I don't understand why this one was far better than rejected propositions
<hcarty>
Alpounet: One could definitely use up 3 months creating a nice OCaml'd plot interface to a plotting library. But I think, if plotting is the intent, then a focus on making a very nice interface to something which already exists would be a better use of time
<flux>
hcarty, I've actually used a small piece of software I've written myself
<hcarty>
flux: I'd recommend the PLplot bindings for a start, if you want to make some plots :-)
<hcarty>
Alpounet: There's the gnuplot binding, PLplot which I wrote the bindings for, another PS/latex-based library which I don't remember the name of...
<hcarty>
It is, of course, their money to fund what projects they see fit :-)
<hcarty>
I'm rather surprised that they chose another "from the ground up" plotting library
<hcarty>
Ocamlviz seems like it could be a useful tool though
<hcarty>
It seems like something of an odd selection
<hcarty>
Alpounet: Interesting
2009-05-11
<hcarty>
Yoric[DT]: Ah, ok. Just curious.
<hcarty>
Yoric[DT]: Is the Batteries build-plan to move away from ocamlbuild?
<Camarade_Tux>
hcarty, looks like mlgmp is not abandonned (even though its makefile looks like it has been made for gcc3 [which is what made me overreact]) :)
<Camarade_Tux>
hcarty, gmp is one of the two exceptions
<hcarty>
Camarade_Tux: Interesting. I didn't know non-stdlib libraries were fair game for use in the shootout
* palomer
looks at flux and hcarty and Camarade_Tux
<hcarty>
And more of a lack of installed dependencies
<hcarty>
palomer: Then that sounds like less of a bug
<palomer>
hcarty, there are type errors
<Camarade_Tux>
hcarty, maybe, I'll see by the end of the week ;)
<hcarty>
Camarade_Tux: Is that an offer to adopt it? :-)
<hcarty>
It's a complex module though, so it certainly may have bugs in some cases
<hcarty>
palomer: I've compiled sexplib before - one attempt at compilation may be a little premature to call it "uncompilable" :-)
<hcarty>
palomer: Otherwise not even local functions are allowed to create values of the private type
<hcarty>
palomer: You need a signature for the private keyword to be useful, unfortunately
<palomer>
hcarty, won't the private keyword do the same?
<hcarty>
jli: You can use that with module signatures to make the age type opaque to outside users
<hcarty>
palomer: There are tutorials on ocaml-tutorial.org as well as links to other information to get you started
<hcarty>
palomer: I don't think that the manual is up to date with the changes in camlp4 in 3.10 and later
<hcarty>
jli: Yes
<hcarty>
You could use both if you want (variant with each constructor having its own associated record type)
<hcarty>
jli: If you have more than one then you would likely need a variant of some sort
<hcarty>
jli: Depends on the data you are using. If there is only one "Something" then it is likely to be cleaner to use a record
<jli>
hcarty: hm, okay. seems like using records would make the code more concise while still allowing pattern matching. is that true, or am I missing something?
<hcarty>
jli: I think all of the methods involve pattern matching of some sort
<hcarty>
robocop: It's a common question and is in a FAQ somewhere - it seems that most folks run in to it at some point :-)
<hcarty>
robocop: So while both types may have the same name, if they were redefined at some point then it can lead to that error
<hcarty>
type_lex or tree was probably redefined somewhere
<robocop>
hcarty: yes.
<hcarty>
robocop: Is this from the toplevel?
2009-05-09
<hcarty>
negacthulhu: DrOCaml is a plugin for using OCaml with DrScheme
<negacthulhu>
hcarty: What's DrOcaml?
<hcarty>
DrScheme is 209mb on my system
<hcarty>
negacthulhu: It has a Scheme compiler/interpreter, libraries and other goodies. I've only used it for its DrOCaml plugin though.
<hcarty>
Camarade_Tux: I just downloaded it... but I'm not particularly concerned with a few hundred MB toy sitting around
<Camarade_Tux>
hcarty, iirc I have a 80-100MB emacs but drscheme is like 260MB =/
<hcarty>
negacthulhu: rlwrap has a lot of other goodies ... some word completion, filename completion
<hcarty>
mfp: Word
<hcarty>
negacthulhu: I certainly use vim for OCaml
<hcarty>
Camarade_Tux: True, but it's a but more than just a toplevel wrapper. And it's not much bigger than Emacs (though emacs does bring more with it)
<hcarty>
DrScheme + DrOCaml is reasonable as well
<hcarty>
Camarade_Tux: Nifty. It seems to be gaining some momentum.