Re: [Caml-list] Any tool for unit tests as comments in OCaml source?
On 05/14/2012 09:48 PM, Francois Berenger wrote: Hello, What's the gold standard in OCaml to have unit test as comments in source code in order for a tool to automatically extract them and generate a test suite? Thanks, F. Batteries uses a program called qtest to do this; it's within the batteries source tree at the moment. There are plans to move it outside for other projects to use. Docs here: http://batteries.vhugot.com/qtest/ E. -- Caml-list mailing list. Subscription management and archives: https://sympa-roc.inria.fr/wws/info/caml-list Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] Efficient scanning of large strings from files
On 03/19/2012 05:08 AM, Philippe Veber wrote: Thanks Edgar and Jérémie, this indeed seems to be the right track. I just hope that a repeated use of input_char is not 10-100X slower than input_line :o). ph. Quite true - instead of giving the matcher just a single byte at a time, it is more efficient to give it blocks of data, as long as it can keep its state from one block to the next. But its matching internally will be on one byte at a time, normally. I guess with DNA, because of the reduced character set, it'd be possible to get each symbol down to 2 bits (if you're really just using ACGT), in which case, the matcher could run 4 basepairs at a time, but there's a lot of corner issues doing things that way. A lot depends on how much time and effort you're willing to spend engineering something. E. 2012/3/16 Edgar Friendly thelema...@gmail.com mailto:thelema...@gmail.com So given a large file and a line number, you want to: 1) extract that line from the file 2) produce an enum of all k-length slices of that line? 3) match each slice against your regexp set to produce a list/enum of substrings that match the regexps? Without reading the whole line into memory at once. I'm with Dimino on the right solution - just use a matcher that that works incrementally, feed it one byte at a time, and have it return a list of match offsets. Then work backwards from these endpoints to figure out which substrings you want. There shouldn't be a reason to use substrings (0,k-1) and (1,k) - it should suffice to use (0,k-1) and (k,2k-1) with an incremental matching routine. E. On Fri, Mar 16, 2012 at 10:48 AM, Philippe Veber philippe.ve...@gmail.com mailto:philippe.ve...@gmail.com wrote: Thank you Edgar for your answer (and also Christophe). It seems my question was a bit misleading: actually I target a subset of regexps whose matching is really trivial, so this is no worry for me. I was more interested in how accessing a large line in a file by chunks of fixed length k. For instance how to build a [Substring.t Enum.t] from some line in a file, without building the whole line in memory. This enum would yield the substrings (0,k-1), (1,k), (2,k+1), etc ... without doing too many string copy/concat operations. I think I can do it myself but I'm not too confident regarding good practices on buffered reads of files. Maybe there are some good examples in Batteries? Thanks again, ph. -- Caml-list mailing list. Subscription management and archives: https://sympa-roc.inria.fr/wws/info/caml-list Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] Efficient scanning of large strings from files
On 03/16/2012 09:03 AM, Philippe Veber wrote: Dear camlers, Say that you'd like to search a regexp on a file with lines so long that you'd rather not load them entirely at once. If you can bound the size of a match by k length of a line, then you know that you can only keep a small portion of the line in memory to search the regexp. Typically you'd like to access substrings of size k from left to right. I guess such a thing should involve buffered inputs and avoid copying strings as much as possible. My question is as follows: has anybody written a library to access these substrings gracefully and with decent performance? Cheers, Philippe. This is tricky to do, as incremental matching implies DFA-based matching, but returning matching substrings implies backtrack-based matching. The re2 library returns matching substrings by matching forward to find the end of patterns, and then matching backwards on the reversed regex from that point to find their beginning. I don't know if even it supports this on incremental input. Subject to the assumption that starting to match implies either finishing or aborting a match (i.e. once you've started to match your regex, no other match will start before either this match attempt finishes successful or not), this is not unreasonable to do. Without this assumption, it requires tracking many match start locations and somehow knowing which of them match or fail to match. I'm not sure this has been done before. E. -- Caml-list mailing list. Subscription management and archives: https://sympa-roc.inria.fr/wws/info/caml-list Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] Tuples (covariant immutable arrays)
Ok, trivial enough a change. You'll have to make a case for the usefulness of this data structure being in batteries for us to make the change, otherwise, feel free to use the batteries code as a basis for your Tuple data structure. LGPL2.1+linking exception should be sufficiently liberal for most uses. E. btw, link to the docs I meant to include in my first email: http://ocaml-batteries-team.github.com/batteries-included/hdoc/BatArray.Cap.html On Wed, Mar 14, 2012 at 5:12 PM, Lukasz Stafiniak lukst...@gmail.comwrote: On Wed, Mar 14, 2012 at 10:03 PM, Edgar Friendly thelema...@gmail.com wrote: Batteries has a Cap submodule that provides type-level protection for arrays so they can be Read-only/Write-only/Read-write. The same idea with a variance annotation and just read-only access seems to be what you're looking for, no? It seems no, because Cap is invariant, and for a reason: for example, Hashtbl.Cap.of_table says This operation involves no copying. In other words, in let cap = of_table a in ..., any modification in a will also have effect on cap and reciprocally. What I'm thinking about is type +'a Tuple.t with Tuple.of_list and Tuple.of_array both performing a copy. -- Caml-list mailing list. Subscription management and archives: https://sympa-roc.inria.fr/wws/info/caml-list Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] odb questions
On 03/09/2012 09:26 AM, Daniel Bünzli wrote: Without going into the dependency resolving thing, I still think it's an issue. Basically with odb you don't really know what you are downloading. http://oasis.ocamlcore.org/dev/odb/ This page shows the stable, testing and unstable versions of each package available in odb. use --unstable or --testing to get a non-stable version. Unstable is the newest uploaded version, testing is the newest version I've been able to make work. Stable has all been compiled together (sometimes there's version issues between packages). Didn't really think hard about it, but instead of (or complementary to) defining it's own key-value language odb could maybe piggyback on oasis files (pretty easy to parse). There's a lot of info in there (deps etc.). While I agree it'd be nice to just parse oasis files, they're not nearly as trivial to parse as the k=v format. If you can write a small enough parser with no external deps, I'll add it to odb and use its info to supplement the packages file. E. -- Caml-list mailing list. Subscription management and archives: https://sympa-roc.inria.fr/wws/info/caml-list Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] odb questions
On 03/07/2012 08:02 PM, Francois Berenger wrote: Wouldn't it be possible to have 'odb remove foo' just call 'ocamlfind remove foo'? Yes, this is possible. Most details of this are already implemented; the code to do `ocamlfind remove foo` is already implemented as part of --force for reinstalling/upgrading packages that don't ocamlfind remove themselves as part of their `make install`, but... This doesn't remove the package. It only stops ocamlfind from complaining about double installation of the same package. If users want to remove an ocamlfind package, they can type ocamlfind remove foo themselves; it's saving them only a few keystrokes to have an odb alias for the same thing, and even if it were added, it wouldn't work properly in many cases, as it wouldn't deal with executables and any other files installed by a program (documentation, etc.). For myself, when I want to remove something installed by odb, I usually just nuke my whole ~/.odb directory and reinstall the packages I want to keep. Thus my resistance to 'odb --remove foo'. E. -- Caml-list mailing list. Subscription management and archives: https://sympa-roc.inria.fr/wws/info/caml-list Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] odb questions
On 03/07/2012 07:32 AM, Daniel Bünzli wrote: Hello, A few questions about odb. 1) Is it possible to specify in ~/.odb/packages a remote packages file (instead of just individual remote packages) ? Not at the moment, but this is an interesting idea. The only support for remote packages is the querying of oasis-db. The protocol is nearly trivial, so you're welcome to make your own server (can be just a plain web server serving static text files) and set the odb repository URL to it. 2) How does odb find out and manage dependencies ? How can I list them before installing a package ? Odb uses findlib to determine what libraries are installed. For executables, the unix command `which` is used. In the works is extracting the version of executables from running the command with `-version`. The other end of this is handled by odb's metadata that specifies things like where to get the source code, dependencies, installation requirements, and other useful information for installing. There are two sources for this metadata: 1) oasis-db by http 2) packages files locally. The packages files are parsed on startup, if odb needs info about a package not in this cache, it queries oasis-db for the metadata. I like the idea of printing deps without installing, and it should be pretty easy to implement. It'd probably suffice to just print the whole metadata; it's quite readable. Maybe metadata + dependency check will satisfy your needs? 3) Are multiple versions of the same package supported (à la homebrew on osx) ? This is supported in two ways. First through environment variables that basically switch between different ocaml installations / ocamlfind root paths. Odb relies on findlib to manage libraries, and it supports this through tweaking install paths. The other way is to have packages batteries1 and batteres2 that both install different versions of batteries, and as long as they register in findlib with the names batteries1 and batteries2, odb will treat them as different. 4) Is something like odb install -file package.tbz possible ? It's planned to be able to give a full package info on the command line, so this would be more like: odb tarball=package.tbz deps=odn,batteries The use case for 4) is both for testing and so that I can instruct my users once they have downloaded a tbz and went through the README that they can just install it with that command (provided they have installed other deps). The current way to do testing is to put a line in your local packages file (two locations that are scanned for one: ~/.odb and the odb script dir), and use the info there for testing. Then once you've got it working, make a simple _oasis file for it, and upload it to oasis-db - then everyone will gain access to it automatically. Daniel P.S. I think odb should use a odbcmd scheme. Instead of just installing on odbpkg. The former scheme has better scaling opportunities. Except I don't intend odb to scale. It's hovering right around 500 lines of code, and if I can keep it around that size, I'll be happy. I don't intend odb to ever have a `odb remove foo` command, nor an `odb update`. Maybe I'll have an `odb upgrade`, but I'm happy leaving this as `odb --upgrade`. Odb's goal is to be an 80% solution, and it was that a while ago, I think. It's approaching 90%, and I'm going to try to avoid it feature creeping to 100%. Oddities should be handled by the package installers themselves or the metadata repository as much as possible, leaving pretty little work for odb. E. -- Caml-list mailing list. Subscription management and archives: https://sympa-roc.inria.fr/wws/info/caml-list Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] Can one implement greedy/inline data structures in ocaml?
On 03/07/2012 09:41 AM, Goswin von Brederlow wrote: The task then needs pointers to each of the lists data structures creating cycles. Not good for ocaml. It also would waste memory for 2 pointers (per list). Cycles are fine for ocaml, pointers are pretty cheap, and I think the answer to your question is no - there's a regularity to values that's required by the garbage collector, and what you seem to want is the ability to inline nested structures without pointers, and OCaml's data representation doesn't allow this, mainly because of the tag word needed by the GC. Beware premature optimization. E. -- Caml-list mailing list. Subscription management and archives: https://sympa-roc.inria.fr/wws/info/caml-list Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] odb questions
On 03/07/2012 10:47 AM, Daniel Bünzli wrote: Okay. Would be nice to have the support in the tool and documentation on how to make your own package source (basically GET on a ~/.odb/packages file ?). Package distribution should be distributed. one file per package, filename is package name, contents are same format as rest of packages line but with \n between key=value pairs instead of space. By 2) you mean what is described in Local packages here : https://github.com/thelema/odb ? Because the syntax for specifiying deps is not documented. Deps are just a comma-separated list of package names, with optional version numbers in parentheses. I'll document this in the packages file now. IMHO a package should be identified by a name and version. I've been thinking about this for a long time, and the full consequences of this involve not only deep changes to odb internals, but also expose the code to a ton more edge cases that need to be handled, as well as possibly some NP-hard problems of resolving version dependencies. Odb may go this way if needed, but the current practice of having a single string as the package identifier is sufficient for my use, so... Pity. I like odb's down to earth approach. You're more than welcome to fork and build a better odb. I may even steal any good ideas you have and put them back in my odb. :) E. -- Caml-list mailing list. Subscription management and archives: https://sympa-roc.inria.fr/wws/info/caml-list Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] How an exception could be an argument
Here is an example of giving an exception as an argument to a function: let run_or ~cmd ~err = if Sys.command cmd 0 then raise err and an example usage: let config_fail = Failure (Could not configure ^ p.id) in run_or ~cmd:(sh configure ^ config_opt) ~err:config_fail; The problem with your code seems to be that you're passing in a result, so the exception is being raised outside your try...with block. OCaml's eager evaluation means that you'll probably have to pass in a function and an argument (or just a unit function), meaning that your ||| will be much uglier: let (|||) (f,x) (g,y) = try f x with Nothing - g y ((fun () - raise Nothing), ()) ||| ((fun str - str), ii) E. On Fri, Feb 17, 2012 at 1:16 PM, Pierre-Alexandre Voye ontolog...@gmail.com wrote: Hello, I'm trying to implement a scala concept partial application in which one can chains pattern matching function. If the first failed, the second is tried. It seems it is impossible to give an exception as argument to a function. exception Nothing;; let (|||) a b = try a with | Nothing - (try b with | Nothing - raise Nothing);; val ( ||| ) : 'a - 'a - 'a = fun (raise Nothing) ||| jj;; Exception: Nothing. But if I try : try (raise Nothing) with | Nothing - (try jjwith | Nothing - raise Nothing);; - : string = jj Is there a workaround ? Regards, P-A -- - https://twitter.com/#!/ontologiae/ http://linuxfr.org/users/montaigne -- Caml-list mailing list. Subscription management and archives: https://sympa-roc.inria.fr/wws/info/caml-list Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] Fwd: interval trees
I struggled with this too, but if you read the wikipedia page http://en.wikipedia.org/wiki/Interval_tree, he's implemented a centered interval tree. Yes, there's a lot of complications needed to insert and remove, but what he's done works for static interval trees. His lookup function is `int - interval list`, not `int - bool`, so he must keep all the intervals that overlap the center point so he can return them. It's useful to have them sorted by left endpoint as well as right endpoint. I might have used arrays for them instead of lists so that binary search is doable, but if they're small, it doesn't matter much. E. On Wed, Feb 15, 2012 at 10:21 AM, Goswin von Brederlow goswin-...@web.dewrote: Francois Berenger beren...@riken.jp writes: Hello, I did a naive implementation of interval trees for float intervals. It is available here: https://github.com/HappyCrow/interval-tree I wonder if it is possible to construct the trees in a tail recursive fashion. Maybe I knew how to do this when I was still at university. Regards, Francois. | Node of (* x_mid left_list right_list left_tree right_tree *) float * interval list * interval list * interval_tree * interval_tree Why interval list? You only need a single interval in leafes and none in other nodes (although it can help to store min and max in each node). You are also missing insert and remove operations, which is the actually hard part in this. Inserting an interval might require merging the rightmost interval left of the root and the leftmost interval right of the root. So you would have 2 removals and one insertion of a combined interval, which complicates balancing the whole thing efficiently. That is the part I'm struggling with. MfG Goswin -- Caml-list mailing list. Subscription management and archives: https://sympa-roc.inria.fr/wws/info/caml-list Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs -- Caml-list mailing list. Subscription management and archives: https://sympa-roc.inria.fr/wws/info/caml-list Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] Package installation assumptions made by odb
On 02/13/2012 06:01 AM, Arnaud Spiwack wrote: I see an immediate problem with packages that install several executable files (for instance, Melt provides a library and a collection of tools, none of them named melt, by the way). I haven't spent time looking more than superficially into oasis or odb yet, but it strikes me as a possibly important limitation. It looks like the executable is now named melt-build. In this case, odb would expect the melt project name to be melt-build so that its simple logic can detect if melt is already installed. This does not have any affect beyond changing the name that must be typed on the command line to install melt (`odb melt-build` instead of `odb melt`), and the name for dependencies by other projects (projects depending on melt would have to specify `dep=melt-build` instead of `dep=melt`). Also, if melt installs an ocamlfind library named melt, then its odb package name could be melt or melt-build, depending on which part of melt should be used to detect its installation. At the moment, odb doesn't really do version handling (mainly because it's difficult to get a version number from an executable), although this is a weakness where odb might improve. This assumption of executables and libraries being named the same as the package isn't critical to the design of odb, it's just a simplifying assumption that works quite well (and would work for melt up to the last version when its executable was renamed). If there's good reason to have more complex installed-program detection, this is easily doable, but the workarounds are simple enough at the moment that this doesn't seem to be a problem. E. -- Caml-list mailing list. Subscription management and archives: https://sympa-roc.inria.fr/wws/info/caml-list Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] Fwd: interval trees
On 02/11/2012 12:38 PM, Goswin von Brederlow wrote: On Fri, Feb 10, 2012 at 10:07:05AM +0900, Francois Berenger wrote: I need to use an interval tree. Biocaml has one, batteries have imap/iset, nice! Anyone have something like this but for non-overlapping intervals and allowing interval insertion and removal with merging and spliting of the internaly used intervals? Yes, IMap / ISet (borrowed from camomile and improved) do this. I assume biocaml's is the same. E. -- Caml-list mailing list. Subscription management and archives: https://sympa-roc.inria.fr/wws/info/caml-list Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] pattern matching on integer intervals
On 01/21/2012 01:14 PM, Pierre Chopin wrote: Hi, I am trying to do pattern matching on unicode characters, represented by integers. I would like to do something like that let f c = match c with 0xff .. 0xfff - foo I know we can pattern match over char intervals but It doesn't be to be the case for char intervals. Some I have two questions: Is there a better way of doing what I am doing and why is it possible to pattern match over char intervals and not int intervals? The author of Camomile wrote IMap and ISet to efficiently store maps/sets over a large domain where large ranges are the same. You may be able to use these DIET trees from camomile or from batteries to accomplish something along the lines of what you want. E. -- Caml-list mailing list. Subscription management and archives: https://sympa-roc.inria.fr/wws/info/caml-list Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] is there a more concise way to write this?
On 01/20/2012 03:37 AM, David Allsopp wrote: Actually, it's possible that with more cases it might be faster - it's eliminating the allocation (at some point) of all the tuples needed for the match case, Doesn't the ocaml compiler not allocate the unnecessary tuples? https://ocaml.janestreet.com/?q=node/90 it potentially eliminates a lot of linear comparisons to find the correct match case (I don't think that the compiler would be able to optimise that to a hash-based or index-based lookup) Isn't the compiler's compilation strategy for match cases able to build an optimized tree of comparisons in cases like this? I agree there's no easy index or hash strategy for this, but I'd expect it to turn this pattern matching into the equivalent of: if a then if b then [a;b] else [a] else if b then [b] else [] E. -- Caml-list mailing list. Subscription management and archives: https://sympa-roc.inria.fr/wws/info/caml-list Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] is there a more concise way to write this?
On 01/20/2012 04:38 AM, oliver wrote: More concise does not always mean better readable or more performant. You apply the same kind of selection for both values. I can't measure readability, but I did throw together a quick benchmark to test the different methods. Please take no offense at this - I'm sure that the responses were headed much more towards readability than performance, so comparing them on performance is totally unfair, and this in no way judges the people whose names I've used to label the solutions. Maybe not surprisingly, the original match-based code came out fastest, and List.filter the slowest. Here's the result summary: demello (83.95 ns) is probably (alpha=7.88%) same speed as friendly (88.68 ns) which is probably (alpha=23.96%) same speed as vuillion (96.68 ns) which is 34.6% faster than robert (147.94 ns) which is probably (alpha=8.43%) same speed as ferre (154.63 ns) which is 70.7% faster than lin (527.64 ns) which is 17.1% faster than lefessant (636.43 ns) which is 31.1% faster than lin2 (924.24 ns) Source code and full results follow. E. - let o = 1 and v = 2 let demello = function | (true, true) - [o; v] | (false, true) - [v] | (true, false) - [o] | (false, false) - [] let robert (out, value) = (if out then [o] else []) @ (if value then [v] else []) let b2l b x = if b then [x] else [];; let ferre (out, value) = b2l out o @ b2l value v;; let maybe b v c = if b then v :: c else c let vuillion (out, value) = maybe out o (maybe value v []) let (|) x f = f x (* no %revapply yet *) let lefessant (out, value) = [] | maybe value v | maybe out o let lin (out, value) = List.filter (fun x - x) [out; value] let lin2 (out, value) = List.map snd (List.filter (fun x - fst x) [(out, o); (value, v)]) let friendly (out,value) = if out then if value then [o;v] else [o] else if value then [v] else [] let test f n = for i = 1 to n do ignore(f (true, true)); ignore(f (true, false)); ignore(f (false, true)); ignore(f (false, false)); done let () = Bench.bench_n [ demello, test demello; robert, test robert; ferre, test ferre; vuillion, test vuillion; lefessant, test lefessant; lin, test lin; lin2, test lin2; friendly, test friendly; ] | Bench.summarize ~alpha:0.05 -- Measuring: System Clock Warming up Estimating clock resolution (1.44 us) Estimating cost of timer call (1.60 us) Benchmarking: demello Ran 32768 iterations in 1.68 ms Collecting 300 samples, 28127 iterations each, estimated time: 431.61 ms N: 300 Inter-quartile width:16.65 ns, Full range: (43.99 ns,525.38 ns) Outliers: 7 (2.3%) High Mild, 19 (6.3%) High Severe, mean: 83.95 ns, 95% CI: (75.16 ns, 88.32 ns) std.dev.: 48.91 ns, 95% CI: (27.18 ns, 61.20 ns) Benchmarking: robert Ran 16384 iterations in 2.96 ms Collecting 300 samples, 7956 iterations each, estimated time: 431.66 ms N: 300 Inter-quartile width:19.52 ns, Full range: (102.86 ns,644.99 ns) Outliers: 6 (2.0%) High Mild, 9 (3.0%) High Severe, mean: 147.94 ns, 95% CI: (141.11 ns, 153.17 ns) std.dev.: 53.76 ns, 95% CI: (22.29 ns, 68.36 ns) Benchmarking: ferre Ran 16384 iterations in 2.71 ms Collecting 300 samples, 8683 iterations each, estimated time: 431.64 ms N: 300 Inter-quartile width:25.01 ns, Full range: (104.02 ns,795.03 ns) Outliers: 6 (2.0%) High Mild, 11 (3.7%) High Severe, mean: 154.63 ns, 95% CI: (149.85 ns, 168.24 ns) std.dev.: 64.76 ns, 95% CI: (46.73 ns, 100.11 ns) Benchmarking: vuillion Ran 32768 iterations in 8.24 ms Collecting 300 samples, 5724 iterations each, estimated time: 431.66 ms N: 300 Inter-quartile width:26.91 ns, Full range: (38.71 ns,1.60 us) Outliers: 14 (4.7%) High Severe, mean: 96.68 ns, 95% CI: (72.67 ns, 115.55 ns) std.dev.: 193.29 ns, 95% CI: (99.28 ns, 244.72 ns) Benchmarking: lefessant Ran 4096 iterations in 2.32 ms Collecting 300 samples, 2543 iterations each, estimated time: 431.72 ms N: 300 Inter-quartile width:147.38 ns, Full range: (346.26 ns,4.15 us) Outliers: 3 (1.0%) High Severe, mean: 636.43 ns, 95% CI: (602.68 ns, 664.49 ns) std.dev.: 277.24 ns, 95% CI: (114.65 ns, 400.85 ns) Benchmarking: lin Ran 4096 iterations in 2.04 ms Collecting 300 samples, 2891 iterations each, estimated time: 431.73 ms N: 300 Inter-quartile width:190.01 ns, Full range: (305.90 ns,1.86 us) Outliers: 2 (0.7%) High Severe, mean: 527.64 ns, 95% CI: (514.62 ns, 556.02 ns) std.dev.: 152.73 ns, 95% CI: (117.57 ns, 225.48 ns) Benchmarking: lin2 Ran 4096 iterations in 2.49 ms Collecting 300 samples, 2371 iterations each, estimated time: 431.71 ms N: 300 Inter-quartile width:252.57 ns, Full range: (505.02 ns,5.90 us) Outliers: 10 (3.3%) High Severe, mean: 924.24 ns, 95% CI: (863.30 ns, 973.78 ns) std.dev.: 469.52 ns, 95% CI: (247.89 ns, 617.19 ns) Benchmarking: friendly Ran 16384 iterations in 1.49 ms Collecting 300 samples, 15769 iterations each, estimated time: 431.63 ms N: 300 Inter-quartile width:15.57 ns, Full
Re: [Caml-list] is there a more concise way to write this?
On 01/20/2012 08:58 AM, oliver wrote: On Fri, Jan 20, 2012 at 08:29:09AM -0500, Edgar Friendly wrote: [...] if a then if b then [a;b] else [a] else if b then [b] else [] [...] For me, the original pattern matching code looks much easier to read. I agree - this was not meant to be a suggestion on how to make the original code easy to read, but instead to point out that it's as efficient as this ugly optimized code. I included it in my benchmark as well for only this reason, to verify that the original code was as efficient as it. E. -- Caml-list mailing list. Subscription management and archives: https://sympa-roc.inria.fr/wws/info/caml-list Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] is there a more concise way to write this?
On 01/20/2012 09:12 AM, David Allsopp wrote: Maybe for this case with two variables, yes - but it can't do that indefinitely: as the number of variables increases, the code size increases exponentially. true, the right way to generalize this is to use vuillion's `maybe` function that prepends conditionally. My main point is that the original match statement is not bad in efficiency, and does, in fact, run 35% faster for the 2-variable case. E. -- Caml-list mailing list. Subscription management and archives: https://sympa-roc.inria.fr/wws/info/caml-list Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] Let-less syntax for coreML
On 01/04/2012 08:30 AM, Diego Olivier Fernandez Pons wrote: I think the biggest thing the community can do to improve OCaml is not to tweak around with language design. It's to improve the library packaging situation. Then just do it. I have, and the result is odb[1]. It backends with oasis-db[2], meaning if you upload your oasis package, it will be installable via odb, including deps. After finding out about barbra[3], a similar project with a different starting point, I stole many of their good ideas, and now have support for a local `packages` file that provides metadata for packages not available through oasis-db. This packages file allows installation of packages available from arbitrary URLs (anything curl-able), git, svn, cvs, hg, darcs, as well as local directories. For a large number of package examples (plus non-examples of packages that fail to auto-install through make/omake/oasis), look here: https://github.com/thelema/odb/blob/master/packages Contributions of additional packages welcome, fixes to the programs that don't auto-install (See the bottom half of the packages file) are doubly welcome. E. [1] https://github.com/thelema/odb [2] http://oasis.forge.ocamlcore.org/oasis-db.html and http://oasis.ocamlcore.org/dev/odb/ [3] still in stealth mode, maybe I shouldn't have stolen their thunder by mentioning them -- Caml-list mailing list. Subscription management and archives: https://sympa-roc.inria.fr/wws/info/caml-list Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] Hashtbl and security
Not a problem, other than memory waste (which doesn't matter the key). Hashtbl.add prepends to the front of the list, so it'll be fast. And Hashtbl.find will match the head of the list, and return quickly too. Hashtbl.find_all will have to go through the whole list, but that's expected. E. On Fri, Dec 30, 2011 at 12:40 PM, ri...@happyleptic.org wrote: I will probably tell something very stupid, but HTML specs do not prevent a client to post 1M values with the same name, so whatever your hash function you cannot do much, can you? The simplest solution I can think of that prevents all attacks of this kind (but could reject some valid POST in theory) would be to store the bucket lengths and use it to detect and reject obviously biaised insertions. -- Caml-list mailing list. Subscription management and archives: https://sympa-roc.inria.fr/wws/info/caml-list Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs -- Caml-list mailing list. Subscription management and archives: https://sympa-roc.inria.fr/wws/info/caml-list Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] Re: how could the community help with Oasis-DB; towards a CPAN for OCaml?
On 12/17/2011 06:27 PM, Daniel Bünzli wrote: I tried to use Oasis on one of my projects. I got stuck at the very begining. I am on MacOS, there is no binary installer, and no instructions for MacOS users. It told me a bunch of dependencies were unsatisfied when I tried to compile. Agreed. Installing the dependencies on osx is just too painful. But as I said before on this list, instead of providing binary installers, I think it would be much more productive for users and oasis devs to be able to bootstrap oasis provided with a raw ocaml install and a reasonably posix compliant unix system (let's pretend I didn't follow the discussion on ocaml for windows). I also agree that a binary package is much less satisfactory anywhere with a compilation environment. I'd love to get a report on how well odb can be used on mac. Its second test of usefulness was being able to install oasis, which has a *ton* of deps. It passed this test a long time ago, and should install oasis just fine. If you have ocaml and findlib installed, odb should work for you. Of course, let me know via its bugtracker or #ocaml on IRC if you have any problems. E. -- Caml-list mailing list. Subscription management and archives: https://sympa-roc.inria.fr/wws/info/caml-list Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] Some comments on recent discussions
On 12/16/2011 07:39 AM, Alain Frisch wrote: We don't necessarily need a full-blown packaging system, with dependency tracking, versioning, automatic download, etc. At first, maybe. In the long run, any friction in the system of inter-package dependencies grinds away at the composability of OCaml packages from different authors into a single solution. This is the reason I support oasis and wrote odb, and this is the reason that everyone out there has their own stdlib. Barriers to having package dependencies hinder the reuse of other people's code except in simplistic copy-and-paste of source code fashion. This seems to be something that the haskell community has gotten right[1]. Whenever I run into a haskell package, it's common for it to have 5 or more dependencies on other packages, and those packages to have deps on others, etc. And this *isn't* a problem for them. I surmise that the haskell community has greased the process of dependencies sufficiently so that there is almost no friction in external dependencies. In our community, external dependencies are painful - the existence of even one external dependency in batteries has been problematic for our users[2]. Furthermore, many people avoid using batteries because they don't want external dependencies for their own project. Why? Because dependencies are a pain. To a great extent, we're stuck doing manual dependency resolution not just inside a project (mostly solved by ocamlbuild), but also between projects (mostly solved by findlib). And because of the friction here, we're stuck in a community of tiny dependency trees and lots of re-inventing the wheel. What's the next step? Contribute to oasis with patches? Oasis-ify your code and upload to oasis-db? Fix GODI/mingw? Build a proper dependency analysis system that can determine package dependencies from special comments in source files and compile them correctly *without* separating that metadata from the source file? Something else? Find your own pain-point in the current system and *fix* it. Maybe a simple, crude, just barely good enough fix. But share that fix with the community, and we all benefit, and can push forward a campaign to remove the pain of external dependencies from OCaml. E. [1] I'm speaking as an observer only, having no real experience with haskell [2] Batteries has removed its last required external dependency as of 2.0beta, but it has had internal a package that should be an external dep since before 1.0, so is still imperfect. -- Caml-list mailing list. Subscription management and archives: https://sympa-roc.inria.fr/wws/info/caml-list Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] Some comments on recent discussions
On 12/10/2011 03:32 PM, Andrei Formiga wrote: The question is: what should be done? What must be done to enable OASIS-DB? Sylvain has worked with me to enable auto-installation of oasis-db packages via odb[2]. There's not a large repo of packages[1], but most of it is auto-installable (run odb to get a list), as long as you have ocaml and findlib to start from. The dependencies are automatically handled and installed from source. I even have confirmation that it works under windows, although it definitely needs cygwin there. The repo could use some love with people uploading[3] new packages to it. Just provide a tarball and optionally a link to the tarball on some other website. Oasis dependencies are detected automatically, packages w/o an _oasis file need to have deps specified manually. Odb is able to install findlib-enabled projects that use ([./configure ] make make install), (omake omake install) and oasis' setup.ml for building. This last option is able to execute whatever sequence of configure, make and install commands are needed for your project, without replacing the current infrastructure. Files uploaded to the repo are available with odb --unstable, they have to be manually approved to become part of the default --testing. I hope that in time, the --stable option can become default. Odb also installs by default to ~/.odb/lib. --sudo tells it to use sudo for global install, --have-perms tells it to install to the global repo without sudo. If anyone wants to auto-detect permissions on the ocamlfind global, we can get rid of --have-perms. I'm on #ocaml most of the time, and will get back to you if I'm away. Tell me how things work or don't. E. [1] http://oasis.ocamlcore.org/dev/browse [2] http://github.com/thelema/odb [3] http://oasis.ocamlcore.org/dev/upload -- Caml-list mailing list. Subscription management and archives: https://sympa-roc.inria.fr/wws/info/caml-list Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] Some comments on recent discussions
On 12/10/2011 04:12 PM, ri...@happyleptic.org wrote: What I'd really like is a way to mix any version I want of the packages I install, especially experimental versions for the packages I want to test or contribute to. I stopped using GODI some time ago because I wanted master of ocaml and batteries but stable versions of everything else. So I ended up rolling my own makefile-based installation/upgrade tool which is both annoying and archaic. Is this in the planned feature list? This is possible currently, by using the --stable, --testing and --unstable flags when installing different packages. Of course, the downside of this is that there's no guarantee or test of compatibility between packages and different versions of OCaml (and possibly each other). Oasis packages can have versioned dependencies, which helps, but the only real guarantee I think that odb can make is that the stable repo all works with each other. Maybe the testing repo too, sometimes, but definitely not the unstable repo. The above all assumes that the versions you want are packaged and in oasis-db. Auto installation from repositories (or local directories) has been considered, but there's some more code to add, as currently the oasis-db server parses _oasis files for deps, and odb is designed to be extremely lightweight. On that note, one more thing about odb - it has no configuration or database of what packages are installed. It doesn't even have the ability to remove a package (not that this couldn't be hacked up in not too much time for library packages). If you ask it to install a package, it checks for deps by asking findlib what's installed. It doesn't try to control things as much as GODI seems to. It just does the minimum necessary to get the job done. This means it plays as nicely as possible with packages installed by whatever other means you wish, even GODI. E. -- Caml-list mailing list. Subscription management and archives: https://sympa-roc.inria.fr/wws/info/caml-list Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
[Caml-list] Re: how could the community help with Oasis-DB; towards a CPAN for OCaml?
On 12/10/2011 04:44 PM, Gabriel Scherer wrote: Could you (or Sylvain) make a more precise picture of how exactly the community could help in the Oasis-DB effort? My opinion is that oasis-db+odb is good enough for wider use. I don't know what plans Sylvain has for the oasis-db server side, but what's currently provided is good enough to make many people's lives easier. Is the priority to upload package (then maybe the warning on the webpage advising not to do it seriously should be changed), or are there other things we could help with, for example development aspects? Who/where should we ask for advice/help when we have issues? Any current work in packaging things for oasis-db will almost certainly be not lost by future updates. Worst case, if the database side of the server gets re-designed, all it has to do is re-import the tarballs and everything will be fine. AFAIK, only Sylvain can change the warning. As well, he's the one that knows the server side of things. I have experience dealing with some of its ... subtleties, but no ability to fix. For the client end (downloading, installation) - that's entirely me, and I'm happy to work with people on IRC (which I find myself doing often with beginners) or over email. A few months ago we tried to organize an OCaml packaging sprint, in which in particular Hezekiah M. Carty was of great help. Do you think we could restart a similar effort in the short future? Probably more useful would be for people to try packaging the libraries that they use for themselves. I've not made grand announcements so that its users can grow slowly, without huge expectations. It would really help, I think, if: - there was a list somewhere of things other people can contribute I've just started this wiki page: https://github.com/thelema/odb/wiki/SoftwareToPackage listing the status of many pieces of software under oasis-db. Extend. - you talked more about the progress of the effort (I discovered 'odb.ml' by absolute chance a few weeks ago, while I follow almost all OCaml-related information channels); if people don't know about your work, they won't contribute I was trying to share it with a small group to work out the bugs, and then share with more and more, kind of incremental adoption. We'll see if Sylvain's server can handle whatever load comes from this announcement. E. On Sat, Dec 10, 2011 at 10:01 PM, Edgar Friendlythelema...@gmail.com wrote: On 12/10/2011 03:32 PM, Andrei Formiga wrote: The question is: what should be done? What must be done to enable OASIS-DB? Sylvain has worked with me to enable auto-installation of oasis-db packages via odb[2]. There's not a large repo of packages[1], but most of it is auto-installable (run odb to get a list), as long as you have ocaml and findlib to start from. The dependencies are automatically handled and installed from source. I even have confirmation that it works under windows, although it definitely needs cygwin there. The repo could use some love with people uploading[3] new packages to it. Just provide a tarball and optionally a link to the tarball on some other website. Oasis dependencies are detected automatically, packages w/o an _oasis file need to have deps specified manually. Odb is able to install findlib-enabled projects that use ([./configure] make make install), (omake omake install) and oasis' setup.ml for building. This last option is able to execute whatever sequence of configure, make and install commands are needed for your project, without replacing the current infrastructure. Files uploaded to the repo are available with odb --unstable, they have to be manually approved to become part of the default --testing. I hope that in time, the --stable option can become default. Odb also installs by default to ~/.odb/lib. --sudo tells it to use sudo for global install, --have-perms tells it to install to the global repo without sudo. If anyone wants to auto-detect permissions on the ocamlfind global, we can get rid of --have-perms. I'm on #ocaml most of the time, and will get back to you if I'm away. Tell me how things work or don't. E. [1] http://oasis.ocamlcore.org/dev/browse [2] http://github.com/thelema/odb [3] http://oasis.ocamlcore.org/dev/upload -- Caml-list mailing list. Subscription management and archives: https://sympa-roc.inria.fr/wws/info/caml-list Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs -- Caml-list mailing list. Subscription management and archives: https://sympa-roc.inria.fr/wws/info/caml-list Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] Some comments on recent discussions
On 12/10/2011 04:49 PM, ri...@happyleptic.org wrote: I will try to use it for some time. But your description of it does not match my dreams. Ideally, I would `odb install this-package --version=X.Y.Z`, and `odb install another-one --branch=master`, and odb would upgrade and/or rebuild what's required. Very similar to the gentoo package system from what I know. Thank you anyway for not being selfish with your time. Requesting specific package versions is not currently supported by the server, but if Sylvain can add something, I can probably support it in the client. Odb's job is only to automate the boring parts of package installation, finding deps, downloading tarballs, extracting, building, installing. It's not a package manager. It's an 80% solution, not an integrated, 99.9%, takes control of everything solution. E. -- Caml-list mailing list. Subscription management and archives: https://sympa-roc.inria.fr/wws/info/caml-list Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] Re: Caml bug tracker: downtime scheduled from december 5th
It seems that anonymous access to the bugtracker is no longer available, is this accidental? E. On Thu, Dec 8, 2011 at 2:40 AM, Maxence Guesdon maxence.gues...@inria.frwrote: On Thu, 1 Dec 2011 10:20:23 +0100 Maxence Guesdon maxence.gues...@inria.fr wrote: Hello, Mantis[1], the bug tracker used for OCaml, will be down from december, 5th at the end of the morning. At this date, we'll move the caml site to a new server. The DNS change should be transparent for the web site, which should remain available all the time. This is the occasion to upgrade mantis while moving it to the new server too. Mantis will be available anew when the DNS change is propagated, which can take some hours or days. At last, the DNS change was made. Mantis is up again. If you encounter problems accessing caml.inria.fr, please tell us (caml-webmaster AT inria.fr). Regards, -- Maxence Guesdon -- Caml-list mailing list. Subscription management and archives: https://sympa-roc.inria.fr/wws/info/caml-list Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs -- Caml-list mailing list. Subscription management and archives: https://sympa-roc.inria.fr/wws/info/caml-list Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] beginners or not (Was: build problem with 3.12.0; no ocamlrun in /usr/local/bin)
On 06/28/2011 09:38 AM, Mihamina Rakotomandimby wrote: A kind of ocaml-dev mailing list, I think. As far as I can tell, this kind of discussion takes place somewhere private. Maybe inside INRIA, maybe with Caml Consortium members only. I think it's a good idea to open things up, but this kind of change is likely not a 'build it and they will come' change. Especially with OcamlPro working on compiler improvements, there's room for open discussions on improving OCaml the language and OCaml the base distribution. E. -- Caml-list mailing list. Subscription management and archives: https://sympa-roc.inria.fr/wws/info/caml-list Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
