<wmeyer`>
hcarty: :) yes, agreement it's a cool idea. Still it is, you can get it now easily for cheaper prices.
<hcarty>
wmeyer`: Good luck with ocamlbrew on ARM - I hope it goes smoothly. From what flux said it sounds like it should if you are running it as a normal user rather than root.
<hcarty>
wmeyer`: I have an Atrix, not currently in use. I never got the lapdock because they were so expensive initially, but it is/was a cool idea.
<wmeyer`>
hcarty: Today I think I will be testing ocamlbrew on ARM too :-). I think I will be testing that quite extensively soon.
<hcarty>
flux: Testing an updated odb.ml against your existing rpi brew would be a good start. If that works, then a clean ocamlbrew installation would be nice to hear about :-)
<hcarty>
flux: There have been updates to odb.ml related to root/sudo, but I don't know if they are in the master branch yet.
<hcarty>
thelema: I thought there was an official OCaml 4.x-ready ocamlnet release, but there is not. I'll likely wait until something official comes out before trying to get it ready for odb.
2012-08-05
<hcarty>
flux: Thanks for the test and report. It sounds like you and thelema are working through it well. If there's anything I can do on the ocamlbrew side please let me know.
<flux>
hcarty, not sure what wen't wrong, but it turns out my binaries want to have /usr/local/share/camomile/database/general_category.mar even though I installed it to /opt/ocaml..
<hcarty>
s/entail/include/
<hcarty>
thelema: What does the rewrite entail?
<hcarty>
flux: I'm glad it worked at least part of the way!
<flux>
hcarty, darn, failed
<flux>
hcarty, so maybe you're right about those day/two, batteries will probably take quite a while :)
<flux>
hcarty, now it has compiled and installed ocaml...
<Anarchos>
hcarty it remebers when i embedded the ocaml toplevel in a graphical gui. I had pain to do that correctly.
<hcarty>
Anarchos: And shell support and a few other items.
<hcarty>
thelema: I've sent pull requests with patches to uint and the zeromq bindings which should make them odb-able under OCaml 4.x. I'll try to get ocamlnet updated as well if I have time this week.
<hcarty>
flux: Talk to you in a day or two :-)
<hcarty>
fasta: My expectation is that there won't be much documentation available until the module interfaces become more stable.
<hcarty>
fasta: There are compiler libraries installed. If you search on the mailing list you'll find links to some basic documentation, along with warnings that the provided libraries are likely to change over the next few releases.
<hcarty>
That's what I was going to suggest :-) I'd be happy to hear if ocamlbrew works on a raspberry pi.
<hcarty>
fasta: They did
<hcarty>
fasta: Do you mean compiler libraries?
<thelema>
hcarty: it's been on the todo list for a while, and someone was working on it; dsheets, maybe
<hcarty>
I expect that's not a bad thing to have in general for odb
<thelema>
hcarty: I think I can write a toposort on top of the current property-list structure in just a few lines of code
<hcarty>
thelema: I'm just thinking from a simplicity of code perspective. But removing a dependency doesn't hurt.
<thelema>
hcarty: don't need ocamlgraph to do a topo-sorting of packages.
<hcarty>
True. Having tests beyond "does it build and install" would be quite helpful :-)
<hcarty>
thelema: A wrapper around odb.ml could be a start. Or an "odb-thick.ml" which uses ocamlgraph to generate a topological sorting of the available packages.
<hcarty>
.
<hcarty>
thelema: It would certainly be useful. It's another nifty feature that would be nice to steal from CPAN
<hcarty>
Thanks for testing
<hcarty>
thelema: Yep. Rock on.
<thelema>
hcarty: awesome; hopefully bob will be happy.
<hcarty>
thelema: Thanks for the notice. I just uploaded, tested, and promoted a new xstrp4 release
<thelema>
hcarty: xstrp4 needs its a new version uploaded for 4.00
2012-08-03
<hcarty>
I think using an mmap'd Bigarray is the way to go
<thelema>
hcarty: okay, so no marshal...
<hcarty>
thelema: They are being read by a program written in another language on another OS.
<thelema>
hcarty: not that I can think of.
<hcarty>
thelema: Does Batteries provide a more efficient way to write out an array of numbers (floats or ints) in binary form than writing them one at a time with IO.write_(i32|i64) and IO.write_(float|double)?
2012-08-02
<hcarty>
adrien: I think that would work as well, but I'm not sure it's any less complicated than what I pasted, and it adds another (admittedly useful elsewhere) dependency
<hcarty>
adrien: If I understand the code correctly you need to provide your own matching function.
<adrien>
hcarty: hmmm, doesn't ocamlfind let you "find" with your own function to store resultts?
<hcarty>
( =~ ) is an infix Pcre.pmatch
<hcarty>
adrien: Yep - I think that will work well enough
<hcarty>
adrien: I was looking through it and didn't see anything
<adrien>
hcarty: ocaml-fileutils
<hcarty>
Along the lines of val glob : regex -> path -> file_name list
<hcarty>
Is there an equivalent to Perl's glob in OCaml?
<hcarty>
.away
<hcarty>
thelema: I'm not too worried about the script piece, although having a prominent section in any documentation and release notes explaining why people might get "Unbound module Batteries_uni" would be helpful :-)
<hcarty>
thelema: Thanks, that's what I'm going with.
<thelema>
hcarty: as for your particular problem, I'd recommend requiring "open Batteries" and requiring threads if compiled with 1.x
<thelema>
hcarty: my current plan is to not have a batteries_uni module in 2.0. If backwards compatibility is important, I may add a small script that does s/Batteries_uni/Batteries/
<hcarty>
iZsh: But that doesn't have to impact this particular library
<hcarty>
iZsh: There is - Batteries for no threads under 2.x
<hcarty>
So the choice comes down to: (a) 'open Batteries' and accept that anything using this library (HDF4 bindings) will need to enable threads if it is also using Batteries 1.x or (b) 'open Batteries_uni' which removes that threads requirement under 1.x but breaks under 2.x.
<hcarty>
In the specific case I'm looking at, threads aren't required. So Batteries_uni would be fine. However, that module will presumably go away when Batteries 2.0 arrives.
<hcarty>
If the library won't have to change otherwise when going from Batteries 1.x to 2.x, should it 'open Batteries' or 'open Batteries_uni'
<hcarty>
iZsh: It is easy to fix, but it adds some extra consideration when a library depends on Batteries
<hcarty>
thelema: In this case I assume Batteries_uni would be an alias for Batteries
<hcarty>
thelema: Will Batteries 2.x have a Batteries_uni for backwards compatibility?
<hcarty>
I found some old myocamlbuild.ml code... I think I had tried to address this before.
<f[x]>
hcarty, you can also try to mingle with bytecomp_c_compiler
<hcarty>
f[x]: No, sadly not.
<hcarty>
f[x]: That's what I expected as well. I'll ping gildor and submit a bug if it is one.
<hcarty>
Anarchos: A wrapper around gcc for the HDF4 library which links/includes the appropriate directories and libraries, given how the library was built
<f[x]>
hcarty, investigate why ByteOpt: -cc doesn't work
<hcarty>
f[x]: I'd rather not go to that extreme :-) I only want to build the .c files for this library with that wrapper.
<hcarty>
f[x]: h4cc is a wrapper around gcc, so I'd like to replace calls to gcc with calls to h4cc
<hcarty>
As in - the flag is not passed to the ocamlc call
<hcarty>
I've tried ByteOpt and NativeOpt: -cc h4cc, but that doesn't seem to do it.
<hcarty>
Is it possible to change the C compiler used via _oasis?
2012-07-31
<hcarty>
thelema: I expect that I won't have time to contribute much - but is there a pre-2.0 TODO list available?
<hcarty>
thelema: Excellent, thanks
<thelema>
hcarty: output_file
<hcarty>
I suppose I can check...
<hcarty>
thelema, mfp: Is there a write_file as well?
<hcarty>
thelema: Not a problem - I'm just glad it's there
<hcarty>
That's a nice addition in 2.0 :-)
<thelema>
hcarty: sorry, added in 2.0
<hcarty>
mfp: Doesn't appear to be
<hcarty>
let write filename content = File.with_file_out filename (fun out -> IO.nwrite out content)
<hcarty>
mfp: Which version of Batteries?
<mfp>
hcarty: I was looking for it the other day and ended up implementing it that way... only to find much later BatPervasives.input_file
<hcarty>
let read filename = File.with_file_in filename IO.read_all
<hcarty>
thelema: Each one is one or two line function, but still handy to have out of the box.
<hcarty>
thelema: Do you see a use in having a File.read(_string)/File.write(_string) in Batteries?
<thelema_>
hcarty: thanks for your help testing our packages.
<hcarty>
diml, thelema_: Thank you for the quick updates!
<hcarty>
thelema_: testing has been pushed to stable; ocamlbrew now installs OCaml 4.00.0 by default
<hcarty>
thelema_: If utop 1.2.1 fixed your issue then I'd like to push the current testing packages to stable
<hcarty>
diml: Would you mind uploading utop 1.2.1 to oasis-db, or would you like one of us to do so?
<hcarty>
diml: Which version of findlib is that?
<hcarty>
diml: How did you install 4.00.0?
<hcarty>
Drat. I wonder if it's a utop bug or feature conflict.
<hcarty>
thelema_: Does your .ocamlinit work under the vanilla toplevel in 4.00.0?
<hcarty>
thelema_: Any luck with the 3.12.1 testing?
<hcarty>
thelema_: Some of the Toploop stuff may not be required under utop. It does a lot of initialization work on its own.
<hcarty>
thelema_: But it worked in 1.1?
<hcarty>
thelema_: Looks good here for 3.12.1
<hcarty>
I'm trying them from unstable now under OCaml 3.12.1
<hcarty>
thelema_: utop + deps haven't been pushed to testing yet
<thelema_>
hcarty: all done, thanks though
<hcarty>
thelema_: I have some idle cores on my system here if they can be of service
<hcarty>
thelema_: Wonderful news all around
<thelema_>
hcarty: looks like jeremie released a 4.00 compatible utop. It's up to me to update batteries so ocamlbrew can default to 4.00. Luckily I'm testing the fixed version now; it's passed the tests under 3.12, now testing under 4.00
2012-07-30
<hcarty>
fasta: If you want the addition, provide it as a patch on the OCaml bug tracker. If it is considered to be valuable then it will be added.
<hcarty>
adrien: Yes, I saw the abiguity when I typed it :-)
<adrien>
hcarty: factorial 0? 1 second for all inputs? ='(
<hcarty>
Hooray!
<hcarty>
I want my OCaml to go infinitely faster. X seconds to compile, as X -> 0!
<hcarty>
Out of curiosity - if it's already been established that no one here has an issue with the toplevel file loading performance, why is this argument going on?
<hcarty>
Or printf "%s\n%!" some_string
<hcarty>
Or use prerr_endline/eprintf
<hcarty>
mcstar: As far as I know that is not possible
<hcarty>
thelema_: Neato
<thelema_>
hcarty: yes
<hcarty>
thelema_: Will there be a OCaml 4.00.0-compatible release of Batteries 1.x?
2012-07-28
<hcarty>
diml: Thanks for the update. I don't want to update ocamlbrew to use OCaml 4.00.0 by default until utop is ready as well.
<diml>
hcarty: i will release utop this week end if i have time or next week
2012-07-27
<hcarty>
I may give up on camlimages for now.
<hcarty>
Drat. omake doesn't build with OCaml 3.12.1 due to -warn-error A as well.
<hcarty>
Indeed.
<hcarty>
No luck with camlimages. It's having trouble detecting system libraries (libpng, libtiff...)
<hcarty>
I found it by clicking on the "OMake Home" link from the camlcity site :-)(
<hcarty>
If '-warn-error A' is removed from the build then omake builds and installs under 4.00.0
<hcarty>
Yep
<hcarty>
And I'd like to try out the latest camlimages version on OCaml 4.0 to see if it works.
<hcarty>
thelema_: That's been my experience. Unfortunately it is still used in some projects, including camlimages.
<hcarty>
It seems like omake in particular manages to break with each new OCaml release.
<hcarty>
-warn-error A is a painful thing, at least in release versions software
<Drakken>
hcarty other languages are also missing a lot of complexity-management features that OCaml has, and there are probably more that are worth working on.
<hcarty>
Drakken: You can get good performance for most applications. I'm not sure that any language can do much better than that on its own, short of the C and assembly worlds.
<Drakken>
hcarty I don't know what applications I might have to or want to work on in the future. I love the mostly-functional approach of OCaml, and it would be nice to know that I can get the maximum possible performance out of it in all applications.
<bitbckt>
hcarty: well put.
<hcarty>
There aren't applications which _can't_ be done due to a lack of concurrent GC, it's just a question of which ones fall to an unacceptable level of performance
<hcarty>
Drakken: That's easier to address the other way around - propose an application which would benefit from some form of parallelism, then assess which method(s) will work for that application.
<Drakken>
hcarty that's what I want to know: which applications really suffer from a lack of multi-core GC, and how do deal with the ones that aren't too much of a problem.
<hcarty>
Drakken: At this point I think that there are a nice selection of methods for concurrency and parallelism in OCaml. They could certainly be more effectively advertised.
<hcarty>
Drakken: The users in the Caml Consortium have a large influence on what ends up in the language
<Drakken>
hcarty the question is what's important to users. I hope that's what the OCaml devs are focussing on.
<hcarty>
Drakken: Not to the OCaml core folks at least :-)
<thelema_>
hcarty: we're all here to help the community, fielding questions and all
<hcarty>
thelema_: Thanks - I had stepped away
<hcarty>
Drakken: s/thead/process/ -- then yes
<thelema_>
hcarty: well said
<hcarty>
Drakken: Philosophical and complexity issues are the main points from what I've read. Time and funding may factor in as well.
<Drakken>
(hcarty)
<hcarty>
Drakken: The least thing I read on that front was talk of having one GC per thread, or something along those lines. I don't know if that was anything more than an idea being thrown around though.
<hcarty>
Drakken: No
<hcarty>
And oh wow - utop v.Next looks like it may have a pretty GUI toplevel environment...
<hcarty>
diml: Do you know when you expect to release an updated utop?
<hcarty>
Hodapp: I'm moving away from MPI to zeromq as it's more appropriate for what I'm currently working on.
<hcarty>
Lwt for concurrency without parallel processing and/or execution of external processes in parallel
<hcarty>
Yes
<hcarty>
Hodapp: A fork-based parallel List.map/iter for simple tasks that I want to perform more quickly; zeromq or MPI for distributed work
<Hodapp>
hcarty: what do you use?
<hcarty>
Hodapp: And there are enough libraries supporting it that I expect others do as well
<hcarty>
Hodapp: I do
<hcarty>
thelema_: Cool, thanks
<adrien>
hcarty: ah, ok :-)
<hcarty>
adrien: It effectively means "You've been fooled/misled" - I'm not sure what the origin is though :-)
<adrien>
hcarty: but, "the wool pulled over my eyes"? I had never heard that :P
<adrien>
hcarty: yeah, I've worked a bit on making it faster (skip .cmo file generation, which turns out to not save that much speed)
<hcarty>
_key_: There are zeromq and MPI bindings as well for more complex tasks.
<hcarty>
_key_: Parmap, Functory, preludeml - these all provide something out of the box
<hcarty>
_key_: Not in the core stdlib, but there are other libraries which support that
<hcarty>
adrien: 7.5 seconds isn't bad
<hcarty>
adrien: You've had the wool pulled over your eyes! How can you be fine with that???
<adrien>
hcarty: I'm fine with the speed as far as I'm concerned ;-)
<hcarty>
pippijn, adrien: If you want to have ocamlbuild not look at unused files, you can tell it to ignore them
2012-07-26
<ssbr->
hcarty: it looks to me like it's really just a runtime/compile-time nomenclature difference. I mean the way things are treated is still fundamentally different
<hcarty>
If those are accurate, it could have something to do with how strict/consisten the requirements are applied
<hcarty>
ssbr-: But I don't know if structural subtyping requires that loss of type information
<hcarty>
ssbr-: I'm not sure. My guess would be that it's for the reason given in that paragraph. Duck typing doesn't lose type information, structural subtyping does.
<ssbr->
hcarty: why aren't structural subtyping and duck typing considered the same thing, as far as objects go?
<hcarty>
ssbr-: The last paragraph has the bit on objects
<ssbr->
hcarty: good to know. I don't know enough about type theory to follow
<hcarty>
ssbr-: With the caveat that you can't get the original object back once you coerce the value into the list.
<hcarty>
ssbr-: I think that comment was made somewhere in there
<ssbr->
hcarty: grk, ocaml seems to solve the second problem just fine
<hcarty>
ssbr-: But you can head in that direction with GADTs if I understand the examples properly.
<ssbr->
hcarty: no, because I want to handle MyOtherConstructor too
<hcarty>
ssbr-: Would type ('a, 'b) t = MyConstructor of ('a, 'b) work for you?
<hcarty>
Thanks all
<thelema_>
hcarty: dump
<hcarty>
What is a good name for the opposite of slurp? Where slurp reads the contents of a file into a string, and its opposite would write a string to a file, creating the file if necessary: val splat : ~filename:string -> string -> unit
<ssbr->
hcarty: that's not a bad observation
<hcarty>
ssbr-: I'm guessing that there is no Array.map2 in stdlib because there is Array.mapi
<thelema_>
hcarty: no worries
<hcarty>
thelema_: Glad it worked, and please don't let me distract you further.
<thelema_>
hcarty: yes, it worked great. I'm distracted from upgrading batteries
<hcarty>
thelema_: Did the OCaml 4.00 brew work for you?
<thelema_>
hcarty: ok, thanks
<hcarty>
thelema_: Harmless warning according to the announcement email
<hcarty>
djcoin: The new -ppx option is a separate item which can be used in place for camlp4 for some items
<hcarty>
djcoin: ocamlspotter uses it for IDE/editor additions (type of the expression under the cursor for example)
<djcoin>
hcarty: Nice! I heard this feature was awaited/could be used for AST transformation and such. Do you know which projects could take advantage of this for this purpose ?
<hcarty>
djcoin: ocamlspotter uses the new -bin-annot functionality
2012-07-24
<thelema>
hcarty: thank you for helping me test
<hcarty>
thelema: Thanks again for getting those fixes in so quickly.
<hcarty>
thelema: I never followed up yesterday, but I've done a fair amount with odb since then and haven't had any trouble yet.
<hcarty>
adrien: I got the same thing
<thelema>
bobry: it works for hcarty with his ocamlbrew script downloading and building 4.00
2012-07-23
<hcarty>
I'm trying a handful of other packages as well
<hcarty>
thelema: Success with ocamlbrew's default set of packages on 3.12.1
<hcarty>
thelema: Good so far. It made it past camomile.
<hcarty>
thelema: Testing again
<hcarty>
Installing camomile\nException: Failure "No download method available for: camomile".
<hcarty>
thelema: Further this time :-)
<hcarty>
thelema: Thanks - trying again. I'll let you know how it goes.
<thelema>
hcarty: once more.
<hcarty>
As part of an oasis install
<hcarty>
thelema: Installing ocamlify
<thelema>
hcarty: what's it' installing to get this error?
<hcarty>
3.12.1
<hcarty>
thelema: On a completely fresh ocamlbrew
<hcarty>
thelema: Failure "Package not in stable repo: tarball=ocamlify-0.0.1.tar.gz".
<hcarty>
thelema: I ran into another issue I think
<hcarty>
It's probably not a good idea for Batteries to be less secure than the stdlib
<hcarty>
I don't know why I had it in my head that the initialization had something magic in C but not the hash function itself
<hcarty>
So it's the hash function itself, not something in the initialization?
<hcarty>
C? That's unfortunate.
<thelema>
hcarty: there's a branch of batteries that has support for 4.0
<hcarty>
thelema: Ah, good to know
<hcarty>
At this point Batteries doesn't due to stdlib changes and lots of others don't work because of the oasis/setup.ml Format module incompatibility trouble.
<thelema>
hcarty: which reminds me - I tried to do the "rebuild the setup" action on oasis-db, and got a failure; need to bother gildor about this
<hcarty>
thelema: Once the packages in oasis-db are updated with oasis 0.3 everything should Just Work with OCaml 4.x
<hcarty>
thelema: Sorry - let "worked" = "Just tried it with Great Success"
<hcarty>
"odb.ml --unstable lwt" worked with a version/4.00 checkout of OCaml
<hcarty>
thelema: Ah, makes sense
<hcarty>
thelema: A quick test looks good here
<hcarty>
thelema: I'll check - thanks for looking into it
<thelema>
hcarty: does 2d22199 fix your problem?
<thelema>
hcarty: I made some changes to the parsing of parameter lists, maybe this broke something...
<thelema>
hcarty: hmm, looking into it
<hcarty>
thelema: I have the same issue with a freshly ocamlbrew'd OCaml 3.12.1
<hcarty>
thelema: I'm running another test now to see if the problem is there under 3.12.1 as well
<hcarty>
thelema: It doesn't seem to matter which path (stable/testing/unstable) I pick or which package I try to install
<hcarty>
yezariaely: There is a patch from ocamlpro which adds support for file-level functors. I don't know how supported/experimental it is.
2012-07-20
<Drakken>
hcarty & thelema thanks.
<hcarty>
Drakken: There is a partial list of Caml Consortium members on the main site
<hcarty>
adrien: Cool
<adrien>
hcarty: yes
<hcarty>
adrien: So LibUi -> libUi.cm*
<hcarty>
adrien: And in that case it uses the Library name as the module name?
<hcarty>
I think it's somthing like Pack: true, but I haven't used it yet
<hcarty>
Or one of the 0.3.0 pre-release versions
<hcarty>
_andre: As of 0.3.0 I think
<hcarty>
Packing will make it a bit easier to completely hide the Util module
<hcarty>
_andre: Then packing or adding a unique prefix will work.
<hcarty>
_andre: That will allow you to have shared names. Otherwise, you would need to take the Batteries approach of adding unique prefixes to the internal module names. You could expose them under a different, common name through each of the main modules (again, like Batteries).
<hcarty>
_andre: One option is the pack the inner modules
2012-07-17
<thelema_>
hcarty: yes, quite complex.
<hcarty>
A significantly more complex competitor from what I can see