<hcarty>
thelema: I don't think the pkg-config would have worked in the first place without them
<hcarty>
thelema: That's what I figured :-)
<thelema>
hcarty: of course.
<hcarty>
thelema: Dev package(s)?
<thelema>
hcarty: that would help for compiling with cairo2, but ocamlfind isn't even detecting cairo2's existence
<hcarty>
thelema, Drakken: Is it CAML_LD_LIRBARY_PATH (or whatever that environment variable is)?
<gildor>
tomprince, hcarty: a tool to prepare Debian package from oasis already exists, it is called oasis2debian
<hcarty>
But even then, installing to /usr/* isn't significantly easier than setting a few environment variables.
<hcarty>
If you are the only user on the system then it may be beneficial to install to /usr/* by default
<hcarty>
Drakken: ocamlfind installs to whatever directory is specified in its configuration file or environment variables
<hcarty>
Also, what adrien said. Defaulting to /usr/local/lib/ is a pain for any user without root access.
<hcarty>
Drakken: Because that isn't how the OCaml ecosystem works :-)
<Drakken>
hcarty every .tar.gz file I download installs to /usr/local/lib/* by default. Why would odb want to avoid that?
<hcarty>
It seems more appropriate for oasis than odb
<hcarty>
tomprince: I think oasis has (or is planned to have) support for this
<hcarty>
One could argue that something like CPAN or odb shouldn't touch system-managed directories
<hcarty>
tomprince: odb is a package manager like CPAN, rather than a package manager like dpkg/apt*
<hcarty>
Drakken: --sudo and related options are nice, but it's handy having odb default to an installation under ~ as it allows it to work with system OCaml installations without touching system directories
<hcarty>
Including the request for IRC log links when relevant and summaries on the mailing list when discussions happen on IRC
<hcarty>
It may be a day or few before I can make any bugfixes, but gasche's comments on pull request 180 all seem reasonable
<hcarty>
thelema: Oh wow... yes, that's quite an oversight
<hcarty>
gildor: Sounds good
<gildor>
thelema, hcarty: @work now, will spend some time talking about oasis tonight around 8-9PM CEST (so in +4/5H), you don't mind waiting to talk about that ?
<thelema>
hcarty: wow, how did we both miss the bug in verify_arg documentation.
<hcarty>
gildor: I think that these things would be useful, but I'm not sure where they would rank versus other development priorities.
<hcarty>
gildor: The implementation would require a bit of effort in assembling multiple versions of OCaml for staging and compiling against, and then running the same test on multiple platforms
<hcarty>
thelema: Good points on both.
<hcarty>
gildor: Yes, as long as the package has an _oasis file a basic implementation should be possible.
<thelema>
hcarty: looks good to me. I guess you could use @raises and @since
<thelema>
hcarty: oh, it does say verify_arg. I had just read that as round.
<hcarty>
thelema: Thanks. I didn't see a bug with "make doc" but I may have missed something
<thelema>
hcarty: hmm, I didn't notice that - I'll investigate
<hcarty>
thelema: His first point in his comment on the pull request I submitted is that there is a bug in the verify_arg doc comment.
<gildor>
hcarty: and just have to detect when new package gets uploaded
<thelema>
hcarty: round?
<gildor>
hcarty: you have ocaml setup.ml -configure/-build/-test that helps you to do that
<gildor>
hcarty: automatic build and testing, can be done on top of oasis
<hcarty>
gildor: Very cool :-)
<hcarty>
thelema: gasche said he saw an error in the verify_arg ocamldoc comment. Do you know what the error is?
<gildor>
hcarty: it already exists in the darcs version
<hcarty>
Code path that is
<hcarty>
thelema: Yes, there would likely need to be a special path for these automated uploads
<thelema>
hcarty: That's a good scripting project; I wonder if curl can do a file upload via http
<hcarty>
thelema: Having an easy "make oasis-db-push" target would be handy, or a similar support from the VCS (git odb-push tag-for-vX.Y.Z)
<thelema>
hcarty: exactly
<hcarty>
Like CPAN I suppose
<hcarty>
Automatic build + test on multiple platforms whenever a package is added/updated
<hcarty>
Automated package testing would be nice
<hcarty>
A more useful feature might be automated pushes to oasis-db through oasis or a related tool
<hcarty>
thelema: I agree that support for automated builds from source repositories would be cool, but I don't think it's much of a killer feature.
<hcarty>
thelema: For my own use Windows is well down on the list of important features. It is probably an important overall feature though.
<thelema>
hcarty: granted. so... a GUI? the ability to install precompiled binaries on windows?
<hcarty>
thelema: Any interest in a round and/or round_to function?
<hcarty>
I'll skip unless for now then
<hcarty>
thelema: Ah, cool
<hcarty>
That could be a separate function - Option.wrap_exn : ('a -> 'b) -> 'a -> 'b option. Option.wrap_exn f x returns None if (f x) raises an exception.
<hcarty>
Or perhaps a list of exceptions to propagate
<hcarty>
thelema: Would unless be more useful if it took an optional list of exceptions to ignore?
<hcarty>
thelema: Also - is BatFoo.Infix the proper submodule naming scheme?
<hcarty>
thelema: Should operators in BatFoo.Infix be included in BatFoo?
<hcarty>
thelema: Well put
<hcarty>
inconsistent. I can't type the last letter of words properly today.
<hcarty>
That may be inconsisten with how other people perceive them
<hcarty>
Rather than logical errors on the part of the caller
<hcarty>
I think of assertions as being more useful for catching local logical errors
<hcarty>
Raising Invalid_argument is also something of a language and library standard. It makes it clear that the arguments provided are not valid.
<hcarty>
Assertions go away if they are disabled. Raising Invalid_argument does not go away.
<hcarty>
everyonemines: As you said, that's not always safe when reading function names. But once you know/trust some code it helps.
<hcarty>
everyonemines: Primarily for readability and ease of deducing the intent of code.
<hcarty>
assert <> invalid_arg
<hcarty>
verify_arg came first, then the more general verify
<hcarty>
everyonemines, thelema: That's true. Like I said, if it went away I wouldn't miss it too much. I wrote it originally to act as a more general form of verify_arg;
<thelema>
hcarty: it gets brevity points, but for me loses on clarity - if/then raise is quite clear, verify could do anything.
<everyonemines>
hcarty: Not everyone will agree with you there.
<hcarty>
s/quickld/quickly/
<hcarty>
thelema: That said, I have found "verify ...;" to be more quickld readable than "if expr then raise ...;"
<hcarty>
thelema: I use verify_arg quite often. I only use verify in a few places, so if it went away I wouldn't be horribly upset.
<everyonemines>
hcarty: I actually don't really use findlib. If I need to use a library in multiple places I make a symbolic link.
<hcarty>
But your proposal could be useful in some cases too
<hcarty>
Yes
<hcarty>
No, I was thinking like printf
<hcarty>
verify could be renamed to verify_exn to help avoid naming collisions
<hcarty>
Do you think it's worth adding both verify_arg and verify_argf?
<hcarty>
thelema: Maybe an extlib-ism
<hcarty>
Understood
<hcarty>
thelema: Should I fork master or v2 for these additions?
<hcarty>
"might want to stay with verify for consistency" - I'm not sure what you mean
<hcarty>
I use ( |? ) fairly often, although it does bite me when I forget that it doesn't short circuit.
<hcarty>
unless and ( |? ) could live in BatOption
<hcarty>
thelema: What about verify_arg/verify_argf?
<thelema>
hcarty: yes, although I'm not so sure about verify and unless going into default namespace
<hcarty>
thelema: Would you be interested in some or all of these additions: http://vpaste.net/y5NAH
<hcarty>
everyonemines: OCaml + findlib is already a large improvement over OCaml on its own :-)
<hcarty>
thelema: A source list to go along with the rest of the package metadata
<hcarty>
thelema: That's may be something that would fit more easily into oasis-db
<thelema>
hcarty: I'm working on odb-from-github, but don't have a good solution for the metadata needed to connect packages to where to get them
<hcarty>
everyonemines: It's different. It is lighter and arguably easier to package for. GODI still has more features, particularly with respect to upgrading libraries and OCaml itself.
<hcarty>
thelema, ygrek: Ok, I haven't tried any Windows builds yet.
<thelema>
hcarty: I've tried those, and couldn't get them to work right
<hcarty>
everyonemines: I think ocamlpro or ygrek provides a Win64 binary of some sort
<hcarty>
The only modifications, IIRC, were to the build system
<hcarty>
thelema: Ulib as in the stdlib extensions from the OCaml CVS/SVN repository, not Ulib for Camomile replacement
<thelema>
hcarty: from ulib? ulib is in v2
<hcarty>
thelema: Additions from Ulib might be nice, but those can presumably happen during the 2.x release cycle
<hcarty>
I've used this for my own local Batteries-derived stdlib. myArray.mli = include module type of Array include module type of BatArray val ...
<hcarty>
That may or may not be considered a good thing...
<hcarty>
thelema: Just that they could make interface management simpler. "include module type of Stdlibfoo" in batFoo.mli reduces code duplication and (more closely) matches the Batteries API to the underlying OCaml stdlib
<thelema>
hcarty: were you wanting to use them for something?
<hcarty>
Ok, that's what I thought. Thanks.
<hcarty>
thelema: Sorry, I meant features like "module type of" and first class modules
<thelema>
hcarty: I think it has; I'll double check now
<hcarty>
thelema: Are you still thinking of Batteries v3 as a time to move to using OCaml 3.12 features in Batteries itself?
<hcarty>
thelema: Do you know if the Batteries v2 branch has an updated BatMap.S to match the OCaml 3.12.x stdlib updates to Map.S?
2011-11-19
<Drakken>
hcarty okay thanks. Do you know if this qualifies for the Ocamlbuild category (instead of Ocaml general)? Or is Ocamlbuild only for sources that go into the compiler itself?
<hcarty>
Drakken: Submit a bug report + patch if you have one on the bug tracker
2011-11-18
<hcarty>
Drakken: If it works, you would probably need ;; after that block
<hcarty>
That works out well
<hcarty>
thelema: Do you think that will make it into 2.0?
<thelema>
hcarty: yes, gasche has a prototype in it.
<hcarty>
thelema: There was some talk in the Batteries world about adding something along the lines of type comparison_t = Less_than | Equal | Greater_than along with modules and functions to use this type (rather than <0, 0, >0)
<hcarty>
Drakken: As long as you switch to the correct plot stream before rendering, you can have as many simultaneous plots as you want
<hcarty>
Drakken: Multiple pages in one plot (PDF or PS for example), multiple distinct output devices (ex. windows or PNGs) and multiple plots rendered on a single surface (ex. 2x2 arrangement of plots on a single PNG)
<hcarty>
Drakken: You can have multiple plot windows
<Drakken>
hcarty I wasn't asking about pages, I was asking about overlapping windows on the monitor
<hcarty>
Drakken: Regarding your PLplot question the other day - you can have multiple plot windows open, and you can have multiple plots on a single page.
<hcarty>
Drakken: pa-do has one and I think that camlp4 includes a simple version as well
<hcarty>
Most of the popular extensions I've seen were ported to the new camlp4.
<hcarty>
thelema: That's fair. Although the volume is likely comparable at this point.
<hcarty>
reynir: Truly
<hcarty>
camlp4 documentation comes down to wikis and reading code, primarily
<hcarty>
reynir: As you noticed, the camlp5 documentation is much more thorough.
<thelema>
hcarty: not by volume, but the maintained ones are in camlp4
<hcarty>
And most extensions are written in camlp4 at this point
<hcarty>
reynir: Keep in mind that camlp5 and camlp4 are not likely to play well together
<hcarty>
Dangerous at times, but fun
<hcarty>
reynir: It is a lot of fun
<hcarty>
reynir: IIRC, camlp5/only-camlp4 was not able to properly preserve comments. camlp4-new has somewhat better support, but there are a number of bugs.
<hcarty>
But it would be cool :-)
<hcarty>
adrien: Who knows if anyone would use it...
<hcarty>
adrien: You do. Because that would be Pretty Cool.
<hcarty>
thelema: For what it's worth, PLplot does support multiple plots, both on the same output and separate outputs.
2011-11-15
<thelema>
hcarty: I think both JSON CSV can be done with `List.print` for a float array
<hcarty>
thelema: True
<thelema>
hcarty: since I'm marshalling about the simplest datatype possible, I'm thinking that I can do the right thing with `List.print` using the right ~first, ~last, ~sep
<hcarty>
Or maybe BatBench should be an external library that depends on Batteries, OCaml's CSV library, one of the OCaml JSON options, a plotting library...
<hcarty>
adrien, thelema: Those are both probably easier to handle with external support functions
<hcarty>
And probably useful... or .bars with ?impulses as an option.
<hcarty>
But it would be very straightforward
<hcarty>
Where Quick_plot.impulses has not been written :-)
<thelema>
hcarty: impressive.
<hcarty>
thelema: Quick_plot.impulses [xs, ys];
<thelema>
hcarty: yes, more likely the second. Except I probably want a bar plot with one-pixel-wide bars
<thelema>
hcarty: I need to get a findlib-enabled lablgtk re-installed
<thelema>
hcarty: float array
<hcarty>
I tried to make PLplot's OCaml interface easy to use (ex. Quick_plot.func [sin; cos] (-3.14, 3.14);). But Archimedes is probably easier to get up and running since it's available through odb.
<hcarty>
thelema: If you get get the distributions in array or function form then you the end user can use whichever plotting library they like
* adrien
points at hcarty
2011-11-10
<hcarty>
vivanov: Just a guess though.
<hcarty>
vivanov: Christophe Troestler does a lot with OCaml + math. Something of his may be helpful if GSL doesn't have what you need: https://forge.ocamlcore.org/users/chris/
<hcarty>
chambart: I'll take a look at the tests, thanks. I haven't done much with OCaml svn trunk beyond peek at commit messages and the changelog every few weeks.
<chambart>
hcarty: You can play with the svn version of the compiler ( and there are quite a few good examples in the typing tests )
<hcarty>
chambart: I'm looking forward to playing around with GADTs in OCaml. I'm unfamiliar with them and what they provide. It will be fun to learn something new.
<hcarty>
thelema: Interesting slides. Thanks for the link.
<hcarty>
thelema: "Confident coding" is one of the things that keeps me in the world of OCaml
<avsm>
hcarty: are you sure ocamlnat is bound by the QPL? the compiler standard libraries are LGPL+exception, i thought
<thelema>
hcarty: totally agreed
<hcarty>
Once that is tested and stable optimizations could be made with a working implementation to compare against.
<hcarty>
thelema, eikke: Thank you for the clarificataion on roots. However, if a function doesn't work with noalloc it's probably best to start with CAMLparam*/CAMLreturn*.
<thelema>
hcarty: I think CAMLparam is only needed for proper GC operation, which means it's registering some kind of roots
<hcarty>
Roots are separate from the CAMLparam macros, if I recall correctly
<hcarty>
eikke: Everything
<eikke>
hcarty: e.g. for int arguments, I see no reason why 'roots' should be defined etc, since they're just unboxed arguments, so Int_val can work as expected, no matter how GC is involved?
<eikke>
hcarty: there's some contradicting information out there
<eikke>
hcarty: but for which types should CAMLparam* be used?
<hcarty>
eikke: Some older code does not, but it's generally considered bad practice and can introduce subtle data corruption bugs if you don't use the CAML* macros
<hcarty>
eikke: You should always use the CAMLparam and CAMLreturn functions
<hcarty>
I've tried the new ocamlnat/jit project. The performance is impressive.
<hcarty>
adrien: Or you could modify ocamlnat to allow communication over some non-local medium (sockets, something networky) and avoid some of the licensing issues
<hcarty>
adrien: I imagine it could, as long as the QPL license terms are acceptable.