<hcarty>
dark, _mpu: let () = ... is often a bit safer
2010-07-21
<hcarty>
From my position of relative ignorance, it looks like it would be a straightforward and useful addition to pa_string in Batteries. But hacking on camlp4 extensions is still mostly opaque to me.
<hcarty>
flux: Ok, thanks
<hcarty>
Is variable interpolation correct?
<hcarty>
What is the proper terminology to describe allowing one to write (let foo = 10 in printf "%(foo:d)")? Similar to how Perl allows "$my_variable" expansion in strings...
2010-07-15
<hcarty>
thelema: Ah, thank you
<hcarty>
thelema: Sorry, performance hit relative to (5.0 *. 7.0)
<hcarty>
thelema: Any thoughts on where that difference may come from?
<hcarty>
thelema: (Unrelated) Under 3.12beta1, BatFloat.(5.0 * 7.0) introduces a performance hit, while BatFloat.(mul 5.0 7.0) does not
<hcarty>
mehdid: Right
<mehdid>
hcarty, PREFIX there is just a Make variable, not an environement variable
<hcarty>
I don't know what the most universally acceptable approach would be, but this patch breaks the GODI and user-configured findlib target cases
<hcarty>
A user may want to install to $HOME/ocamllibs/, specified through a findlib configuration or environment variable
<hcarty>
Relying on `ocamlc -where` is bad too though
<hcarty>
I can't say that I particularly disagree...
<hcarty>
Would it be hard to specify the environment variable in the Debian build system?
<hcarty>
mehdid: I'm not sure how easy/hard it would be
<hcarty>
None of the packages need to speficify an ocamlfind installation prefix from what I understand.
<hcarty>
pkg-lib/ for packages installed with GODI's tools
<hcarty>
The default ocamlfind install location outside of GODI's tools is site-lib/ for a GODI-installed system
<hcarty>
thelema: Likely with environment variables
<hcarty>
thelema: I'm fairly certain the GODI build system takes care of that
<hcarty>
Would it be possible to change the patch to only specify destdir if a PREFIX is given?
<hcarty>
Likely so
<hcarty>
I don't know the specific mechanism
<hcarty>
It Just Works in my experience...
<hcarty>
I'm not sure either
<hcarty>
And GODI has a third for the stdlib
<hcarty>
Yes
<hcarty>
There is one hierarchy for GODI's packages, another for user-installed libraries
<hcarty>
mehdid: GODI doesn't use the same default directory
<mehdid>
hcarty, it shouldn't as it keeps the same default, imo.
<hcarty>
Is the prefix patch going to cause problems with GODI?
2010-07-13
<hcarty>
Nevermind - I misunderstood the purpose of the commit. It was only to allow building against Camomile 0.8.1, not to address the binary relocation problem.
<hcarty>
gildor: Thanks. I checked a recent Batteries commit and it looks like the path is still hard-coded at compile time in the Batteries source.
<gildor>
hcarty: you need to use CamomileConfigDyn module
<hcarty>
thelema: Does a build of Batteries with Camomile 0.8.1 produce binaries without hard-coded Camomile data paths?
2010-07-09
<JohnnyL>
hcarty: fair enough.
<hcarty>
I'm not very familiar with the concept or terminology, so that is about as much as I know
<hcarty>
JohnnyL: I haven't worked with it, but I've seen others mention using JoCaml and Lwt in that context.
<JohnnyL>
hcarty: what's your view of using the Actor model in Ocaml?
<hcarty>
The preludeml library also has a few simple fork-based parallel map and iter functions
<hcarty>
avsm, mfp: Thank you both
<mfp>
hcarty: the OCaml runtime will update the pointer for you if it moves the value: you give caml_register_global_root the address of the value variable
<hcarty>
avsm: For example, if I pass a string to a value (string or array) and the C function keeps a pointer to that in some other structure on the C side
<hcarty>
avsm: Will it prevent a value from being moved by the garbage collector?
<hcarty>
Does anyone here have a reference for caml_register_global_root and related functions, outside of the official manual? After reading the manual I'm not clear on their purpose.
2010-07-08
<hcarty>
I wouldn't know what I know without the assistance from others in #ocaml
<hcarty>
krankkatze: It's ok, I'm glad you got it working
<hcarty>
They all need those tags if they all use Batteries
<hcarty>
krankkatze: Also, you still need the pkg_threads - sorry, I wasn't clear on that earlier
<hcarty>
krankkatze: Are there other source files involved?
<hcarty>
You may be able to be more specific in that, but ocamlbuild needs to know that Batteries is needed in linking as well (IIRC)
<hcarty>
krankkatze: You want "<cgi.*>: pkg_batteries" in _tags
<hcarty>
Oh! I see what is (hopefully) the problem
<hcarty>
krankkatze: To check - Does "ocamlfind list | grep batteries" show anything?
<hcarty>
Is Batteries installed and found by findlib?
<krankkatze>
hcarty: still getting the same error :/
<hcarty>
s/The/Then/
<hcarty>
The "ocamlbuild cgi.native"
<hcarty>
krankkatze: "<cgi.ml>: pkg_threads, pkg_batteries" should do it
<hcarty>
krankkatze: I'm not sure why you still get the error with Batteries_uni, but you can try adding pkg_threads to your _tags line
<krankkatze>
hcarty: I'm having the same error when using the following myocamlbuild.ml
<hcarty>
flux: Perhaps it's just a prank
<hcarty>
krankkatze: The Batteries module also requires threading support. If you use the Batteries_uni module instead of Batteries then you can avoid having to link with the OCaml threading library.
<hcarty>
sgnb: I'm looking forward to that. Hopefully it works well.
<hcarty>
Yes
<hcarty>
It doesn't require Batteries to use, but it is very handy
<hcarty>
krankkatze: Batteries has a myocamlbuild.ml in its source distribution which provides working ocamlfind support, among other things
<krankkatze>
hcarty: what do you mean?
<hcarty>
krankkatze: Batteries comes with a myocamlbuild.ml which does a lot of this for you automatically.
<hcarty>
krankkatze: Or open Batteries_uni instead of Batteries
<hcarty>
krankkatze: You also need to link with the thread library
<hcarty>
thelema: The current listed maintainer is David Teller
<hcarty>
thelema: Do you know if someone is going to/has taken over upkeep of Camomile in GODI?
<hcarty>
Unless I'm misunderstanding the question
<hcarty>
philed: You can't add a 'b value on an 'a list
<hcarty>
rwmjones: Late summer or early fall for the final release IIRC
<hcarty>
rwmjones: X. Leroy gave a rough timeline at the OCaml Meeting
<hcarty>
1;; in the REPL doesn't EPL
<hcarty>
camlp4 3.12 seems to break the toplevel as well
<hcarty>
And it provides things like Float.(1 + 2) = 3.0
<hcarty>
It provides pa_infix, which allows all kind of (potnetially evil) manipulation and creation of infix operators
<hcarty>
flux: Only a small portion
<hcarty>
sgnb: Is there a Debian package for pa-do/Delimited Overloading?
<hcarty>
mfp: Yep, camlp4. After experimentally installing several camlp4 extensions with GODI, bitstream/bitmatch seems to be unaffected, but it's apparently the exception.
<mfp>
hcarty: is that caused by changes in camlp4 or in the language?
<hcarty>
pa_do, type-conv and mikmatch all fail to build
<hcarty>
Lots of camlp4 extensions seem to have problems with 3.12
<hcarty>
I'm not sure, since it's a work-around for a bug in 3.12.
<hcarty>
With that patch applied, Batteries builds under GODI's OCaml 3.12beta1.
<hcarty>
Thank you both
<hcarty>
sgnb: Yes, I found that too - forgot that I had subscribed to it
<hcarty>
thelema: I remember reading something about it, but I haven't found the relevant commit/mailing list message
<hcarty>
thelema: Is there a patch/fix for compiling Batteries' pa_format with OCaml 3.12beta1?
2010-07-03
<Yoric>
hcarty: "Findlib doesn't help with modules which have not been installed (ex. modules which are part of the project you are working on)" -- ok, good remark
<hcarty>
There is a brief tutorial in the PLplot manual in the OCaml chapter as well
<hcarty>
If you try to use PLplot and it gives you external function not available errors then you can "export LD_LIBRARY_PATH=$GODI_BASE/plplot/lib:$LD_LIBRARY_PATH"
<hcarty>
elehack: I need to go, but if you have time please leave a message here and/or email me with the results. I appreciate the testing!
<hcarty>
If the ocaml-cairo GODI package doesn't build with lablgtk2 then that should be fixed as well at some point.
<hcarty>
I need to add a configuration option to not require ocaml-cairo. The Cairo support is provided through a separate module.
<hcarty>
I hope that others find it useful as well
<hcarty>
I wrote the OCaml bindings so that I could do my graduate research plotting from OCaml
<hcarty>
elehack: Thank you!
<hcarty>
It worked on my system, but as one of the developers for the library and the OCaml bindings I'm not a very good test of usability.
<hcarty>
Then it _should_ be a matter of updating the GODI package list and building + installing the godi-plplot package
<hcarty>
It requires having cmake installed, having the requirements for ocaml-cairo installed, and adding a path to LD_LIBRARY_CONF after the install to test
<hcarty>
elehack: If you don't mind, I would appreciate it
<hcarty>
elehack: It's a plotting package - line/point/contour/etc. plots
<hcarty>
Is anyone here on GODI interested in testing an experimental GODI-installable PLplot?
<hcarty>
flux: It doesn't as far as I know
<hcarty>
Experience using the actual syntax may indicate how local modules can be handled better.
<flux>
hcarty, hm, how does findlib work with the project one is working on?
<hcarty>
elehack: That seems reasonable, at least for a first version
<elehack>
hcarty: you can set OCAMLPATH to the root of your source tree to have findlib search it for uninstalled modules. would that be sufficient?
<hcarty>
Yoric: Findlib doesn't help with modules which have not been installed (ex. modules which are part of the project you are working on)
<hcarty>
"use mylib [List; Array]" with mylibList.ml and mylibArray.ml in the current directory for example.
<hcarty>
elehack: One big downside is that this requires a findlib package install to work. It might be nice to allow this for local modules as well.
<hcarty>
It sounds like a very handy syntax though, particularly if it's usable by any module
<hcarty>
It may be a good idea to use "open" or "include" to avoid stepping on existing code with values named use
<hcarty>
Very true
<hcarty>
List = List + BatList, Array = Array + BatArray
<hcarty>
*assume
<hcarty>
elehack: It's probably reasonable to assum a naming convention
<hcarty>
I would prefer something simpler. Could this pa_openin material be used for that purpose?
<hcarty>
elehack: I agree
<hcarty>
elehack: "module E = Enum with Exceptionless" will give you "module E = struct include Enum include Exceptionless end"
<hcarty>
"with" was the only thing new, and pa_with was already provided with Batteries
<hcarty>
Or something along those lines
<hcarty>
elehack: IIRC, that syntax was selected because it added the fewest keywords
<hcarty>
elehack: That's the part I was referring to
<hcarty>
elehack: Yes, it's in src/syntax/pa_openin/
<hcarty>
elehack: In Batteries' pa_openin that is
<hcarty>
elehack: I think it's in pa_openin
<elehack>
hcarty: I can't seem to find that syntax support. pa_batteries in the last beta just adds a couple of open lines.
<hcarty>
Could work well for building SQL statements in a semi-sane manner.
<hcarty>
(Print.printf p"And the we print %{My_module.t}" my_module_t_val) is worth its weight in code
<hcarty>
Particularly with named parameters and how easy it is to extend.
<hcarty>
BatPrint + syntax is excellent.
<elehack>
hcarty: I should go dig for that code. Could save the effort (albeit minimal) of writing it from scratch.
<hcarty>
elehack: Your "use Batteries {UTF8 Enum IO}" idea was in the original Batteries
<hcarty>
proposed
<hcarty>
Very similar to what elehack propoised
<hcarty>
thelema, mfp: That too, but I'm thinking of the module building one
<thelema>
hcarty: previous batteries had a syntax extension that added [open batteries] to the top of the file
<hcarty>
Something along the lines of module List = List with Exceptionless, Labels
<hcarty>
Didn't the original Batteries include a syntax extension doing something like this?
<hcarty>
They would be nice to have. Perl's namespace handling is nice for things like this.
<hcarty>
But if the modules with external dependencies are provided outside of the Batteries hierarchy then the problem is alleviated.
<hcarty>
Which doesn't seem like it would work nicely with OS package management
<hcarty>
mfp: batteries.sqlite3 could pull in BatSqlite3, which would presumably work
<hcarty>
mfp: But that doesn't work for the deb, rpm or GODI case
<hcarty>
Without a constant Batteries, there is no external way to verify if the user has the relevant dependencies.
<hcarty>
mfp: Yes
<hcarty>
mfp: What happens when a user tries to compile Batteries + Sqlite3 code against vanilla Batteries?
<hcarty>
It would be a much cleaner solution to either make these modules true dependencies or keep the external dependency modules as Bat* stand-alones.
<hcarty>
That seems like a bad idea
<hcarty>
mfp: Batteries becomes poorly defined at that point
<mfp>
hcarty: well, batteries.ml could be generated at compile time to include the optional modules that were built
<hcarty>
mfp: BatZip and BatSqlite3, but no inclusion in Batteries
<hcarty>
thelema: Testing
<mfp>
hcarty: it's quite doable in fact. MySQL's API has only val exec : dbd -> string -> result (no separate functions to prepare a statement and bind params, unlike sqlite), so it'd have to go through a string
<hcarty>
There are a number of modules which would benefit Batteries - camlzip, Sqlite3...
<hcarty>
thelema: It seems like something that would be better either as a full dependency or an add-on to the sqlite bindings
<hcarty>
thelema: Yes
<thelema>
hcarty: the ocaml-sqlite library?
<thelema>
hcarty: out of sync how?
<mfp>
hcarty: /me taking a look at the MySQL C API...
<hcarty>
?
<hcarty>
Is it a good idea to add something with an external dependency which could so easily get out of sync
<hcarty>
mfp: That sounds really useful. How easy would it be to extend to Mysql?
<hcarty>
thelema: Using exceptionless modules provides a nice tool for refactoring, but that may not be a good enough reason to keep it around.
<hcarty>
BatteriesE does that is.
<hcarty>
BatteriesL and BatteriesE still also sound appealing to me though - makes it harder to accidentally let an exception slip through.
<hcarty>
elehack: I use the Exceptionless modules in Batteries heavily, but I agree that *_opt would provide an easier to parse interface
<hcarty>
Yoric: Hello
<hcarty>
s/I think/I agree/
<hcarty>
thelema: Yes, I think that, if the Exceptionless modules are dropped, then find and find_opt would be the better choice for Batteries
<thelema>
hcarty: yes, true. we're keeping backwards compatibility, so we can't do that in general.
<hcarty>
IIRC, core does the reverse - find and find_exn
<thelema>
hcarty: almost done, testing now
<hcarty>
thelema: That sounds appealing.
<hcarty>
elehack: I built the OCaml source tree, so that may be part of it
<elehack>
hcarty: did you get any cannot-find-module errors?
<hcarty>
elehack: It doesn't seem to work fully, but it edits files and does syntax highlighting.
<hcarty>
elehack: With the symlink I was able to get it to compile
<hcarty>
I set OCAMLLIB to `ocamlc -where` and put symlinks for lablgtk2 (already exists) and xml-light in `ocamlc -where`
<hcarty>
elehack: Thanks, setting OCAMLLIB fixed the Not_found error for me too
<elehack>
hcarty: I tried to build it yesterday, but with no success.
<hcarty>
I'm hoping to get at least a basic GODI package for PLplot together this weekend.
<hcarty>
derdon: It's on my todo list :-)
<derdon>
hcarty: why didn't you try to contact the developer of the program?
<hcarty>
A Not_found exception is raised, but the compilation script is a .ml run with ocaml, so it doesn't give a backtrace
<hcarty>
Has anyone here successfully built OCaml Editor? I'd like to try it out under GODI but I haven't been successful so far.
2010-07-01
<hcarty>
Likely so
<hcarty>
Batteries will power your OCaml as it TAREs through your data
<flux>
hcarty, yeah.. ocaml doesn't have enough of those trendy and hip names. Totally Awesome Regular Expression (-engine) would fill that void.
<hcarty>
flux: TARE is a fantastic name. It TAREs through data at an TAREible rate.
<flux>
hcarty, maybe it should be called "TARE"
<hcarty>
If the result is Totally Awesome and supports named substrings/matches, then it sounds worthwhile.
<hcarty>
thelema: If you write your own, PLEASE keep the PCRE syntax if possible. We already have three regexp-like syntaxes in OCaml (Str, PCRE and mikmatch)
2010-06-30
<synod>
hcarty: that's my understanding but no updates have occurred
<travisbrady>
hcarty: thank you
<hcarty>
Perhaps OCaml was recompiled but findlib wasn't, for example
<hcarty>
synod: I'm not familiar with OCaml on osx or macports, but it sounds like findlib and OCaml are out of sync
<hcarty>
travisbrady: sexplib is another option. You can write custom toplevel printers. And Batteries has a very nice Batteries.Print (or BatPrint) module which lets you define custom printers for any type and use them with a super-duper-printf-like syntax
<hcarty>
travisbrady: There is a library + syntax extension call Deriving. Also, Batteries + Extlib have dump which dumps the internal representation
<hcarty>
derdon: I'm happy I could help
<derdon>
hcarty: ok. but I thank you anyway cuz you could help me to compile the code succesfully :)
<hcarty>
That's a bug I can't help with right now :-) But I'm glad it compiles for you.
<hcarty>
Then the ; does clear it up, though I think let () = ... in would be easier to read/interpret later on
<hcarty>
The two could have the same result, that is.
<hcarty>
derdon: let () = ... in has a clear precedence. The two could be the same, but I'm not certain.
<hcarty>
derdon: I'm not sure how a ; would play with the precedence
<derdon>
hcarty: and why should I wrap it in ``let () = ...``? I inserted a semicolon after it, and the code compiles but behaves strangely now
<hcarty>
So you could put a "let () =" after line 8 and a "in" before line 15
<hcarty>
Everything from line 9 through line 14
<hcarty>
derdon: Sorry, I should have said the try expression
<derdon>
hcarty: what you mean with the try-block? only the single line which is "print_endline (...)"?
<hcarty>
thelema: Map.Make and its derived modules do have Exceptionless modules, only containing the find function.
<hcarty>
thelema: PMap and Map are missing Exceptionless modules. I'm not able to submit a patch any time soon, but would you like a bug report on github?
<hcarty>
derdon: You're welcome, glad it works :-)
<derdon>
hcarty: ah, now I get it! thanks a lot!
<hcarty>
derdon: As it is, the code does not work as the indentation implies. "IO.close_in input" is considered as part of the Printf.eprintf function call on line 14.
<hcarty>
derdon: If you wrap the try block in let () = ... in then it should fix the problem
<hcarty>
derdon: Your try .. with .. is leaking
<thelema>
hcarty: other than that, the only safety issue is that maybe you'll use a PSet with one type and you think you're using it with a different one, but the compier won't warn you until the two worlds collide
<hcarty>
thelema: Thank you - that makes sense.
<thelema>
hcarty: performance is nearly identical, I think they use the same kind of balanced trees, except the compare function is held in the functorized module for Set.Make and it's in each PSet
<hcarty>
If 3.12 were out I would pass modules generated with Map.Make around. PMap looks like a decent compromise until then.
<hcarty>
thelema: Curious about performance (which I know really requires me to test in my particular use case) and what the safety differences are
<hcarty>
elehack: Thanks for the pointer
<thelema>
hcarty: what do you want to know about the two?
<elehack>
hcarty: look at the introduction to the documentation to Batteries.Set
<hcarty>
Is there a comparison between PMap and Map.Make (PMap from extlib or Batteries) available?
2010-06-29
<hcarty>
It is not in the documentation as far as I can tell, but it is in the pa_string example
<hcarty>
I just found Batteries' pa_string support for named printf elements. That's too cool.
2010-06-28
<hcarty>
avsm: Did you find it easy to work with?
<hcarty>
Neither have I :-)
<flux>
hcarty, indeed!
<hcarty>
flux: Then it must be true!
<flux>
hcarty, I've had the same vision :)
<hcarty>
I have a (perhaps baseless) hope that some day, Lwt will have fork-based parallelism and distributed parallel magic included.
<adrien>
hcarty: ok, I'll try to take a look at it
<hcarty>
adrien: I think that there is an example in Batteries which reads stdout from another process. Don't remember which example it is...
2010-06-25
<hcarty>
Though I don't know if pa_string changes it's expected syntax to match. I haven't tried any of them with revised syntax.
<hcarty>
Some of them should work for both from what I understand
<thelema>
hcarty: none of them indicates revised/original
<hcarty>
thelema: How so?
<hcarty>
That's my best guess. Batteries-Old didn't require that for it's "all-encompassing" use_batteries tag because (IIRC) there was one for revised and one for original.
<derdon>
hcarty: I created a new directory for this
<derdon>
hcarty: even this isn't working!
<hcarty>
thelema: Maybe it's not able to detect if you want original or revised syntax?