<hcarty>
But it doesn't hurt to have some high-profile software depending on Batteries
<hcarty>
thelema: Indeed, and I think it is becoming that.
<hcarty>
thelema: I've noticed. The new coverage is impressive.
<hcarty>
thelema: Pressure in a joking sense... but it is pretty cool that Batteries is being used by something as potential core to the OCaml ecosystem as oasis.
<thelema>
hcarty: yay. There's a number of small compatibility breaks, but there's not been any huge problems needing fixing.
<hcarty>
thelema: On an unrelated note, I tried compiled some software against Batteries 2.0-whatever_is_in_odb without modifying it from Batteries 1.x form and there were no issues. So that's quite nice.
<thelema>
hcarty: pressure?
<hcarty>
thelema: The pressure is on!
<hcarty>
thelema: oasis now relies on Batteries
2012-02-23
<hcarty>
Pervasives.compare will go as deep as it needs to
<hcarty>
pippijn: Given that definition of compare, you could probably just use Pervasives.compare
<hcarty>
pippijn: It will work. I don't know if it will do what you want it to do. But it will work :-)
<hcarty>
pippijn: A bit of magic, but I think the net effect is comparing each string in each list (head to head comparison) until one pair is <>.
<hcarty>
Drakken: Maybe. The only way to know with any certainty is (a) benchmark and (b) look at the generated assembly
2012-02-22
<hcarty>
I'm not sure if a "Perl + OCaml + MySQL" position from a not overtly OCaml company would be ok.
<hcarty>
Are job postings on the main OCaml list considered acceptable? I realize that postings happen there at times, but they tend to be from established OCaml'ers like Jane St.
2012-02-20
<hcarty>
djcoin: _habnabit's suggestion, and your original approach, to compose the functions is probably the most OCaml-y way to do this
<hcarty>
djcoin: Indeed :-)
<djcoin>
hcarty: _habnabit: Well, I guess I can't I have to define recursively the contained type; Given I have to define it in the structure, I can not predict each (in my case) possible fun the contained type will be given.
<hcarty>
_habnabit: Something about recursive functions and polymorphism...
<hcarty>
_habnabit: 3.13 for GADTs; 3.12 for first class modules and more polymorphism goodies
<hcarty>
You may be able to do something with the new 3.12 features. And I don't know enough about GADTs to know if they make such a thing possible.
<hcarty>
djcoin: I'm not sure that's possible, at least not without some trickery
<hcarty>
_habnabit: Variant
<hcarty>
eikke: You're welcome, and sorry for replying to the wrong person
<eikke>
hcarty: #5441 indeed, thanks
<hcarty>
djcoin: The linking order issue is being/has been discussed on the bug tracker and main OCaml mailing list. I don't know what the result was.
<hcarty>
s/is//
<hcarty>
djcoin: Good luck :-) And thelema is the author of odb. odb is provides the real magic behind ocamlbrew.
<hcarty>
djcoin: Yes, I am for ocamlbrew
<djcoin>
hcarty: disclaimer, you are the author ;)
<hcarty>
djcoin: And if you don't want to take that approach, you can look at ocamlbrew's source code (it's a fairly simple shell script) to see what steps are required.
<hcarty>
djcoin: The dimensions of "a bit" depend on the dependencies you have installed :-) But ocamlbrew automates the full build if you have spare CPU cycles and want to give utop a try.
<djcoin>
hcarty: "a bit of effort" :) All right I will check that when I have a few time on my hands. Thanks!
<hcarty>
djcoin: Or you can use ocamlbrew to get a (relatively minimal) OCaml + odb + utop setup in a command or two.
<hcarty>
djcoin: If you want to try oasis-db with GODI, you can grab odb.ml. With a bit of effort you can get utop installed through odb.
2012-02-11
<hcarty>
adrien: Are you using oasis + -for-pack support? Are you happy with the patch?
2012-02-10
<hcarty>
thelema: Thank you once again for your help!
<hcarty>
thelema: Good point
<hcarty>
The parsed results are about the same size as the raw data they come from. Given that, copying the data upfront should have about the same overhead as building a C list then copying the data over to OCaml values.
<hcarty>
thelema: Correct
<thelema>
hcarty: you'd only have to copy the parsed values, not the raw.
<hcarty>
Then convert that to an OCaml list once the C work is done
<hcarty>
thelema: I could push the values onto a C list
<hcarty>
This was tough to track down. GC interaction bugs are tricky.
<hcarty>
That's my other option. It's not clean, but it does avoid copying the data.
<thelema>
hcarty: sounds like you should dowbload the data with libcurl
<hcarty>
I may be stuck with copying the data. That's unfortunate.
<hcarty>
The short version of the process in this case is: Download data with ocurl |> Parse data with C API, returning an OCaml list of values extracted from the raw binary data
<hcarty>
thelema: The C API returns a 'handle' value which stores a pointer to the data internally.
<hcarty>
Well, in this case a binary blob read from a file..
<hcarty>
It's a large binary file being read by a C API
<hcarty>
thelema: That is correct
<hcarty>
thelema: Yes
<hcarty>
I have a bit of a tricky situation. I need to take data from an OCaml string and hand it off to a C function which stores a pointer to that string.
<hcarty>
s/there/this/
<hcarty>
thelema: That makes sense re: string literals. In this case the string is dynamically allocated.
<hcarty>
thelema: Is there a way to prevent that from happening for the duration of the C FFI call? Is there where global roots come into play?
<thelema>
hcarty: yes, strings may get moved by the GC
<hcarty>
I have an OCaml string that I need to access from C. Am I correct in assuming that the address given by String_val(ocaml_string_value) may change after a call to caml_alloc?
2012-02-04
<thelema>
hcarty: oops,n/m, it's actually a bug in the test
<adrien>
hcarty: well, the setting to increase the number of lines used for highlighting has been pointed out on the caml-list
<hcarty>
adrien: It tends to hold together for me in shorter source files, but for anything longer than a few hundred lines... yes, it's going to happen quickly.
<hcarty>
adrien: :-)
<hcarty>
adrien: That's pretty cool. I hope I remember that the next time code folding + OCaml source highlighting breaks for me.
<adrien>
hcarty: built-in
<hcarty>
adrien: Is ctrl+l a built-in, or something added to vim?
2012-01-31
<hcarty>
It looks like filter_map uses a fold so it should be safe.
<hcarty>
Are there any other functions in Set which may have the same fault?
<hcarty>
If you're going to fix it right now then I won't bother
<hcarty>
thelema: Should I file a bug report?
<hcarty>
:-)
<hcarty>
for me
<hcarty>
That works
<hcarty>
My map is: fold (fun elt accu -> add (f elt) accu) s empty
<hcarty>
thelema: Right
<hcarty>
thelema: I'm trying to replace/override each of those functions individually now to see which is the culprit, assuming that is really where the problem lies.
<hcarty>
thelema: re: BatSet - if I include (Bat)Set.Make(Foo) and then override the map and of_enum functions in my set module, my ordering problem goes away.
<hcarty>
thelema: You've mentioned wanting a pure-OCaml regexp module/library for Batteries. Have you seen ocaml-re (https://github.com/avsm/ocaml-re)? If so, what's your opinion of it?
<hcarty>
So rather than saying "I can't find module Foo", first try loading foo.cmo?
<hcarty>
Ah
<thelema>
hcarty: I think it just notices the name of missing module and tries to load that first
<hcarty>
thelema: I'm guessing it works somewhat like a local findlib?
<hcarty>
thelema: That's what I expected as well from reading the code.
<thelema>
hcarty: unless batSet is generating broken sets for you (which seems to be the case), a batset should marshal exactly as well as astdlib set
<hcarty>
The_Average: There are some interesting OCaml-based web programming tools available. Ocsigen is one (
<thelema>
hcarty: most of stdlib's set code is re-implemented in batSet, but not all of it, and the casts are still necessary for the type equality.
<hcarty>
The_Average: OCaml is applicable in a large number of areas. Do you have a specific area of interest for programming (web, games, etc)?
<hcarty>
Or writing programs
<hcarty>
thelema: Strictly functor-based sets. But both functorized and polymorphic sets seem to use the same code internally, so I don't know what impact that has.
<thelema>
hcarty: more in 10 minutes
<thelema>
hcarty: marshalling functions in the polymorphic sets?
<hcarty>
thelema: I'm not using Marshal directly, but I am using xleroy's MPI bindings which, IIRC, use it internally.
<hcarty>
thelema: Do you know if there is anything in 'a BatSet.Concrete.set that would cause problems with Marshal? Or the %identity casts between 'a BatSet.Concrete.set and Set.S.t (which don't make much sense to me, since it looks like stdlib's set code is duplicated in batSet.ml anyway...)
<hcarty>
thelema: Yes, I have tested for existing Ready values a few ways - by printing the full set; by filtering on a Ready status, resulting in a non-empty set (also printed for posterity).
<thelema>
hcarty: you know there's more Ready values because you're looking into the set and finding them there?
<hcarty>
I'll try to come up with a test case here
<hcarty>
thelema: Thank you for testing and confirming
<hcarty>
thelema: It's ok, I'm just glad I'm not the only one seeing it.
<hcarty>
thelema: Then re-add as In_progress
<hcarty>
thelema: Yes
<hcarty>
thelema: In pseudo-match-code: ready a && (not (ready b)) -> ~-1 | ready b && (not (ready a)) -> 1 | compare_priorities a b
<hcarty>
thelema: Yes, effectively
<hcarty>
thelema: No. Other components of the set element are compared in a specific order (priority, submission time, etc.)
<hcarty>
At some point, Done _ jobs are returned by min_elt when Ready jobs still exist in the set.
<hcarty>
Yes
<hcarty>
thelema: Not in a non-functional way
<hcarty>
All Ready jobs should be "less" than other jobs
<hcarty>
thelema: The sorting is first done on the status of the job (Not_ready | Ready | In_progress | Done [`completed | `skipped])
<hcarty>
thelema: Yes, they are processing jobs
<hcarty>
Given that it works in stdlib and doesn't have an obvious fix in Batteries-master, it is probably worth trying to reduce this to a simple test case.
<hcarty>
It doesn't not return the minimum element according to Ord.compare
<hcarty>
min_elt that is
<hcarty>
mine
<hcarty>
Ordering becomes... wrong at some point
<hcarty>
thelema: Yes, and it is somewhat subtle
<hcarty>
And I'm not doing anything fancy with sets
<hcarty>
thelema: The disturbing thing is that there is no reason to expect that it does not
<hcarty>
thelema: Perhaps s/them/[a] and [b]/
<hcarty>
This is somewhat disturbing. The Set.Make bug I'm seeing goes away entirely when going back to stdlib. Batteries-master does not seem to change batSet.ml at all, except to add a few new functions.
<hcarty>
thelema: It does
<hcarty>
Not unless (at least) two or three more thelemas join the Batteries party :-)
<hcarty>
Instead either avoiding stdlib entirely or including all of stdlib in Batteries.
<hcarty>
More than giving up compatibility, it would require not basing any of Batteries on the OCaml stdlib used during compilation.
<hcarty>
It would be nice if a cleaner method were available, but nothing immediately comes to mind.
<hcarty>
That makes sense, although it gets very hairy very quickly.
<hcarty>
So Batteries.Gc and Batteries.Gc313 would exist
<hcarty>
thelema: Handled like Camomile was in 1.x?
<hcarty>
Gc perhaps
<hcarty>
thelema: I think there is another module as well, but I don't remember which one
<hcarty>
thelema: stdlib compatibility that is, due to a few API changes
<hcarty>
thelema: How will OCaml 3.13.x compatibility be handled?
<thelema>
hcarty: I'm still leaning towards just the findlib package name 'batteries', unless someone can convince me that large numbers of people will want to keep using v1 even transitionally
<hcarty>
thelema: Allowing for simultaneous v1 and v2 installations
<hcarty>
thelema: Any thought to having Batteries 2.0 install as batteries2?
<hcarty>
thelema: Sounds like a good plan.
<hcarty>
Ok, that's good to know for planning purposes. I've been holding off on testing any large projects against Batteries-git since I wasn't sure what the future plans were.
<hcarty>
.
<hcarty>
thelema: Not Compatible. Labeled functions, (usuall) no exceptions
<hcarty>
thelema: I haven't tried with master/head yet, as the changes required to test are fairly involved.
<hcarty>
thelema: What is the status of BatteriesNC in 2.x?
<thelema>
hcarty: good question. Does the same code work under HEAD batteries?
<hcarty>
thelema: In short, I think I'm running into a bug in the ordering of Batteries' sets (the same code works as expected when Legacy.Set.Make is used) but I'm not sure the bug is worth tracking down and reporting if 1.x is considered dead.
<hcarty>
thelema: It's difficult to follow the github bug tracker since the bugs are not generally associated with a particular version
<hcarty>
thelema: Are there known issues with Batteries 1.4.1's Set.Make-generated sets?
<Drakken>
hcarty what if it was UNselected and then I exited godi_console? It seems to get selected again.
<hcarty>
Drakken: GODI godi_console remembers whatever installtion/removal selections you made between runs. So if a package was previously selected for installation but not installed, it will still be selected the next time you run godi_console.
<hcarty>
adrien, Drakken: That seems likely.
<Drakken>
hcarty probably the most recent. netpkg did the download, so I don't have the tarball & I don't remember which one it was, and I don't see a -version arg to tclsh.
<hcarty>
oriba: Or source code
<hcarty>
oriba: Where is the documentation for ocaml-ncurses?
<hcarty>
adrien: Ah, that's good. It wasn't that way last time I did a fresh GODI install.
<adrien>
hcarty: <= 8.5 (just checked)
<hcarty>
< 8.5
<hcarty>
Drakken: I think GODI only auto-detects
<hcarty>
Drakken: Do you know what version of Tcl and Tk?
<adrien>
hcarty: oh, I'll check SO, thanks
<hcarty>
adrien: But every linked module has its top level expression run. So if you want something like that it probably makes the most sense to have "let run () = ..." in foo.ml, then use bar.ml with "let () = run ()" to build the executable version.
<hcarty>
adrien: You could have a toplevel expression that only evaluates when a certain flag is passed in Sys.argv
<hcarty>
adrien: There was a stack overflow question about this I think. There may have been some kind of work-around.
<adrien>
hcarty: ='(
<hcarty>
adrien: Regarding your question yesterday about running a code when used as a program but not when used as a library - I don't think that is possible in a direct way, given that OCaml has no "main" function, so every linked module is on fairly equal footing.
2012-01-12
<thelema>
hcarty: I strongly approve of ord (and eq)
<hcarty>
thelema: Hooray :-)
<thelema>
hcarty: yes, stdlib compare will be removed from NC
<hcarty>
thelema: If BatteriesNC does happen, I vote for gasche's Ord over stdlib-like compare functions in addition to the other proposed changes.
<hcarty>
thelema: Quite.
<hcarty>
thelema: I agree
<hcarty>
There is no spooky action at a distance when going from Batteries -> BatteriesNC. There is from Batteries -> BatteriesThreads.
<hcarty>
Threads changes a lot more than calling conventions.
<hcarty>
"No, it does! You just need to open BatteriesNC rather than Batteries!"
<hcarty>
"No, wait, it doesn't..."
<hcarty>
"Hey cool! Batteries have finger trees!"
<hcarty>
However, that really muddies the waters when it comes to figuring out what Batteries is
<hcarty>
That would reduce the development burden - no need to have BatFoo.NC anywhere but in the stdlib-like modules
<hcarty>
thelema: I think that anything not stdlib-like should be kept out of module Batteries if that's the approach taken
<hcarty>
And if BatFooA acts differently than BatFooB then it grealy increases the barrier to entry.
<hcarty>
thelema: But if you do that with BatFoo directly then you lose consistency
<thelema>
hcarty: that was my thinking for the rest of the batteries modules.
<hcarty>
s/of/if/
<hcarty>
But of .Cap sticks around it should probably be NC-only
<hcarty>
Not to mention the BatFoo.Cap modules...
<hcarty>
thelema: Otherwise you have BatFoo.Labels.map and BatFoo.Exceptionless.map, each with a different and incompatible signature.
<hcarty>
thelema: In that case though, you probably want BatFoo.NC only
<hcarty>
thelema: I agree. Two is going to be easier to keep straight than 4.
<hcarty>
If Batteries.Foo always have .Labels and .Exceptionless (where necessary/appropriate) then it makes is easier for users to transition to the BatteriesNC way of thinking if they want to.
<hcarty>
Or that
<hcarty>
If that approach isn't taken then it makes "module Batteries" a PITA to use because every module will behave differently.
<hcarty>
Then, additionally, provide BatteriesSomething with labels and no exceptions, BatteriesLabels with labels and exceptions, BatteriesExceptionless with no exceptions and no labels
<hcarty>
If stdlib compatibility is among the top priorities, then it makes sense to have "module Batteries" be stdlib-like throughout (no default labels, raise exceptions)
<hcarty>
But I don't want to give up BatIO or the pervasive *.print functions or any of the other Batteries goodies
<hcarty>
thelema: I agree. If I weren't already heavily invested in using Batteries in my code I would strongly consider moving to Core now that they have opened up a bit.
<hcarty>
thelema: Consistency. That's one of the benefits of using Batteries.
<hcarty>
Or, if you prefer, Batteries = BatteriesL(abels); BatteriesNolabels = stdlib-like; BatteriesExceptionless = no exceptions
<hcarty>
It's more work initially, but I think it's better to have .Labels and .Exceptionless everywhere, then provide Batteries, BatteriesExceptionless, BatteriesLabels
<hcarty>
But that interface can't be applied directly to both stdlib-based and Batteries-original modules
<hcarty>
That feels very unpolished
<hcarty>
But why is Enum different than Array?
<hcarty>
How is it trivial?
<hcarty>
Sorry, my exceptionless comment was an aside
<hcarty>
No no - the labeling
<hcarty>
If that functor requires map, for example
<hcarty>
You can't provide a functor that works across both
<hcarty>
thelema: But then every Batteries user needs to know which modules are stdlib-based and which ones aren't
<hcarty>
thelema: I'm not sure I agree with exceptionless ... I really like the "limited gotchas" results that come from having foo : ... -> 'a option and foo_exn : ... -> 'a
<hcarty>
Why should there be that big of a difference between BatArray and BatEnum?
<hcarty>
That's horribly inconsistent within Batteries
<hcarty>
thelema: Functors, for example, which expect stdlib-like modules
<hcarty>
thelema: I'm ok with that, it just make it harder to use Batteries with non-Batteries code.
<thelema>
hcarty: I think batteries original modules should be exceptionless and labeled
<hcarty>
thelema: I've been happy with the BatFoo.Exceptionless and BatFoo.Labels approach
<hcarty>
thelema: I'm thinking along the lines of labeled arguments and raising/not raising exceptions.
<thelema>
hcarty: compatibility with stdlib is first priority, but consistency within batteries can often be achieved by extending stdlib modules
<hcarty>
NaCl: My guess is that DynArray.get is meant to match Array.get
<hcarty>
thelema: Which is more important in Batteries during this standardization process - consistency within Batteries, or compatibility/consistency with stdlib?
2012-01-11
<thelema>
roconnor: would you like to ... what hcarty said
<hcarty>
roconnor: If it doesn't exist already, it's probably worth submitting a bug in Mantis
2012-01-10
<hcarty>
It's not more DWIMery than any other abstraction.
<Drakken>
hcarty perl is notorious for two things: overcomplicated syntax and overcomplicated semantics.
<hcarty>
thelema: I get that. But not how.
<thelema>
hcarty: perl-like
<hcarty>
I still don't understand what you mean by perlish.
<Drakken>
hcarty of course it does. .ml is usually the starting point, and .byte or .native is usually the end result. But that means there's some kind of perlish semantic magic going on behind the scenes, and I didn't see anything about it in the user's manual.
<hcarty>
Drakken: That is a fair point. In that case I think it applies to *->.byte
<Drakken>
hcarty and <*.byte> tags apply to .byte->* ?
<hcarty>
<*.ml> tags will apply to .ml->*
<hcarty>
Or rather, <*.mll> tags will apply to .mll->*
<hcarty>
<*.mll> tags will apply to .mll->.ml
<hcarty>
Drakken: No - that's what was said earlier. Entries in _tags only apply to files indicated by that entry.
<hcarty>
Depends on the compilation process. A .cmo or .cmx often still relies on other modules.
<Drakken>
hcarty is that really necessary? Doesn't some of the library code get build into the object once it's compiled?
<hcarty>
If you would like to see the details, ocamlbuild's source is likely to be the best resource.
<hcarty>
The details of the rules can be complicated, but using them is not.
<hcarty>
Drakken: Both
<hcarty>
The rules are riddled with sigils
<hcarty>
Drakken: Which means nothing...
<Drakken>
hcarty which are what I commented on: the rules are perlish.
<hcarty>
Drakken: That distinction comes down to ocamlbuild's rules
<Drakken>
hcarty you're still confusing the target with the source. When you say "compilation of a .ml file", you don't mean the compiler is *producing* source file, you mean it's *using* the source file to *produce* an object file.
<hcarty>
Drakken: How so?
<hcarty>
Drakken: <*.ml>: package(foo) -- This tell ocamlbuild that any compilation of a .ml file requires the findlib package foo
<hcarty>
_tags only apply to the file being processed
<tomprince>
hcarty: I think the Drakken wants to have some tags on the .ml be about generating the file, and some about building the generated file, and how they interact.
<hcarty>
If you're talking about a custom tool that is built, then that tool is used to process something else - that most likely requires custom rules.
<hcarty>
tomprince, Drakken: If that's the case, then tags don't work any differently for generated code than they do for hand-written code.
<tomprince>
hcarty: I think Drakken is asking about how tags work in the case you a.ml is a generated file.
<hcarty>
Drakken: I do not think that a tag on a.ml will carry over to b.ml automatically (assuming b.ml uses a.ml)
<Drakken>
hcarty I mean when the target is already built and the compiler uses it to build something else.
<hcarty>
Drakken: What do you mean by using the target?
<Drakken>
hcarty but in each case the tags apply when *building* the target, not when *using* it.
<Drakken>
hcarty what does "apply" mean? for .byte it means "use tags when building target", but ocamlbuild doesn't build source files.
<hcarty>
Drakken: For example, OCaml byte-code compilation and OCaml native-code compilation may each do different things with the same tag
<hcarty>
Drakken: If you look at most myocamlbuild.ml files there are sections which tie a tag to a specific set of conditions
<hcarty>
or s/ have// ...
<hcarty>
have AN effect
<hcarty>
You could, if you wanted, define tags which only have affect one or the other
<hcarty>
Drakken: No, of course not. There are rules for linking vs compilation as both adrien and I said.
<hcarty>
Drakken: A tag applies to whatever is specified in the _tags file
<Drakken>
hcarty when do tags apply to a target? when it's beign built, or when it's being used to build something else?
<hcarty>
Drakken: You're welcome to use hand-written Makefiles as well, or oasis to hide the details of ocamlbuild.
<hcarty>
Drakken: Sloppy how?
<hcarty>
Drakken: Tags can have different meanings when compiling vs linking
<Kakadu>
hcarty: We'll need qtcreator to edit qml code. It understand only *.pro and cmake project types
<hcarty>
That said, if you're working on Qt it may be worth the trouble to use cmake if it makes other tasks easier..
<hcarty>
Qrntzz, Kakadu: I've only used cmake + OCaml in one project. I would not recommend it if you can avoid it.
2012-01-09
<hcarty>
That seems reasonable
<hcarty>
thelema: I'm torn on 'a option vs ('a, 'b) result. Both have benefits.
<thelema>
hcarty: There are times we may want to provide both t first and x first
<hcarty>
thelema: But I would rather have all of them than none :-)
<hcarty>
thelema: I'll make a more formal reply on-list, but for the record - I like all of those proposed standards, with the possible exception of "t goes first."
<hcarty>
thelema: One of the more interesting uses of camlp4 I've seen.
<hcarty>
I haven't used it beyond compiling and running the included examples, and that was a year or more ago. But it looks cool.
<thelema>
hcarty: interesting../.
<hcarty>
nixfreak, thelema: Or use ciml which is supposed to automate the process a bit - http://chadok.info/ciml/
<hcarty>
adrien: The documentation is certainly easier to find :-)