On 03/13/2012 06:34 PM, Matthias Puech wrote:
This is consistent with how ocamlc/ocamlopt work: separate compilation
is ensured the way you think by bytecode .cmo compilation: to build a
module, you only need the *interfaces* of its dependencies, but it is
unfortunately not ensured when
:-(
I don't understand. Why is it sad to have the *ability* to perform
cross-module implementation-dependent optimizations (at the inevitable
cost of locally damaging separate compilation) *if* you wish?
On Wed, Mar 14, 2012 at 11:31 AM, Matej Košík
5764c029b688c1c0d24a2e97cd7...@gmail.com
Yo,
I don't know if this helps, but I can create arbitrary compilation times with
very small code samples:
let sink (a,f) = f a
let base = ()
let finish () = ()
let step () = ()
let fold (a,f) g = g (a,f)
let step0 h (a,f) = fold (h a,f)
let f z = fold (base, finish) z
let a z = step0 step
There is the cmigrep tool found on http://homepage.mac.com/letaris/ .
I have no idea about current status though;
http://jun.furuse.info/hacks seems to imply it works on 3.12.
On Wed, Mar 14, 2012 at 6:38 PM, ri...@happyleptic.org wrote:
-[ Wed, Mar 14, 2012 at 01:30:29PM -0400, Hongbo Zhang
On Tue, Mar 13, 2012 at 05:52:37PM -0400, bob zhang wrote:
Hi list,
I noticed that Godi can pretty print cmi files, is there already
libraries parsing cmi files?
cmigrep may be worth looking at. It's also a nasty(-ish) hack since
it has to use the compiler sources. I agree it would be
On 03/14/2012 07:14 PM, Hongbo Zhang wrote:
I tried, it does not compile, but it would be not hard to fix, I
guess.
In Debian, we apply the following patches to compile it:
http://patch-tracker.debian.org/package/cmigrep/1.5-9
FWIW, it compiles and runs perfectly well with any OCaml
hello world.
In my application I'm using arrays all over, and lately I've discovered a
couple of bugs related to the fact that I was using the index of one array to
get the element of another array. Since both indexes are int the compiler could
not help me at all. Using private types it seems I
Hi,
Does anyone have a Tuple module that exports arrays as immutable and covariant?
Thanks,
Łukasz
--
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:
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
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
type +'a t = (int - 'a) * int
let get (a: 'a t) i = (fst a) i
let length (a: 'a t) = snd a
let of_array (a: 'a array) : 'a t =
let a' = Array.copy a in
(Array.get a', Array.length a')
should be enough
--
Caml-list mailing list. Subscription management and archives:
Here is a proposal:
https://gitorious.org/gasche-snippets/private-array-keys-type/blobs/master/private_array_key_types.ml
It works by using a functor to generate fresh private types for
keys. Note that the arrays themselves are still polymorphic (no
IntArray FloatArray etc.). The user still
12 matches
Mail list logo
