Re: [Caml-list] make[1]: warning: Clock skew detected. Your build may be incomplete.
skaller
> Hi,
>
> Got my new laptop with a Intel dual core. I get these funny messages. I
> use Ocamlmakefile and ocaml under Cygwin on WinXP.
>
> Any ideas why?
>
> Anyone else getting these messages?
>
> make[1]: Warning: File `libraries/ocaml/date_helper.cmo' has
> modification time 0.0041 s in the future
Regularly?
This is probably a kernel and/or motherboard fault.
I had this problem with my dual core AMD64, only it wasn't
wrong by 0.0041 s .. it was running almost double speed.
The reason is related to the fact my board supports variable
frequency CPU operation: when the load is low, it drops the
CPU frequency, voltage, and fan speeds to conserve power
and reduce noise. I had to disable this feature entirely.
Both Windows and Linux seemed to suffer. On Linux the
problem also went away using non-SMP kernel.
Also, my Linux system (and probably Windows) uses network
time server adjustment. Unfortunately, unlike old synchronisers,
these modern ones just reset the clock, without worrying
about screwing up file times (old ones would just speed up
or slow down the clock marginally until the clock was right).
I have no idea if this is your problem, but warn that time
on some motherboard/SMP kernels is potentially bugged.
It is possible the problem is software is using
the CPU clock for timing, instead of the RTC, since RTC
typically have only very coarse resolution.
In that case, the software is using a clock
which isn't regular. Check your bios, and try turning
off variable frequency CPU operation, see if that fixes it?
--
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net
_______________________________________________
Caml-list mailing list. Subscription management:
http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
Archives: http://caml.inria.fr
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs
Igor Peshansky
> Hi,
>
> Got my new laptop with a Intel dual core. I get these funny messages. I
> use Ocamlmakefile and ocaml under Cygwin on WinXP.
>
> Any ideas why?
>
> Anyone else getting these messages?
>
> make[1]: Warning: File `libraries/ocaml/date_helper.cmo' has
> modification time 0.0041 s in the future
Mattias,
This is probably due to your using a FAT filesystem. FAT filesystems
store file times with a 2-second granularity, so it's not surprising that
make is confused. As a workaround, use NTFS.
I don't believe this is O'Caml-specific. If you want to pursue this
further, we should probably move the discussion to the Cygwin mailing
list.
Igor Peshansky, volunteer O'Caml maintainer for Cygwin
--
http://cs.nyu.edu/~pechtcha/
|\ _,,,---,,_ pech...@cs.nyu.edu | ig...@watson.ibm.com
ZZZzz /,`.-'`' -. ;-;;,_ Igor Peshansky, Ph.D. (name changed!)
|,4- ) )-,_. ,\ ( `'-' old name: Igor Pechtchanski
'---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow!
"Las! je suis sot... -Mais non, tu ne l'es pas, puisque tu t'en rends compte."
"But no -- you are no fool; you call yourself a fool, there's proof enough in
that!" -- Rostand, "Cyrano de Bergerac"
Mattias Waldau
I also tried telling make to use 2 threads, i.e. "make -j 2", and then
the compilation fails after a while. Therefor, I think the most probably
cause is that not all dependencies are included in the Makefile.
Anyone else using Markus Mottl's Ocamlmakefile on a dual-core?
I can live with this, I am just curious.
-- Mattias
Diego Olivier Fernandez Pons
I would like to write a (non intrusive) inline help feature for some
modules I wrote, that would look like
# help MyModule.is_prime;
- : string = "is_prime : int -> bool computes if an integer given as a
parameter is prime"
# help MyModule.probabilistic_is_prime;
- : string = "..."
I can write a function of type 'a -> string which computes the hash key of
the parameter and returns the string associated in a table, but I cannot
do a physical equality based desambigusation for collision since the
equality is typed
let
f = function x -> x + 1 and
g = function x -> x + 2
in (f == f, f == g)
- : bool * bool = (true, false)
let
f = function x -> x + 1 and
g = fun x y -> x + y
in (f == f, f == g)
This expression has type int -> int -> int but is here used with type int
-> int
Does anyone know how I could circumvent this problem ?
Diego Olivier
Jacques Garrigue
> I would like to write a (non intrusive) inline help feature for some
> modules I wrote, that would look like
>
> # help MyModule.is_prime;
> - : string = "is_prime : int -> bool computes if an integer given as a
> parameter is prime"
> # help MyModule.probabilistic_is_prime;
> - : string = "..."
>
> I can write a function of type 'a -> string which computes the hash key of
> the parameter and returns the string associated in a table, but I cannot
> do a physical equality based desambigusation for collision since the
> equality is typed
>
> let
> f = function x -> x + 1 and
> g = function x -> x + 2
> in (f == f, f == g)
> - : bool * bool = (true, false)
>
> let
> f = function x -> x + 1 and
> g = fun x y -> x + y
> in (f == f, f == g)
> This expression has type int -> int -> int but is here used with type int
> -> int
>
> Does anyone know how I could circumvent this problem ?
Short answer:
Help being a metalevel feature, just don't bother and use Obj.repr,
which will converts all your functions to type Obj.t.
(Obj.repr is less dangerous than Obj.magic, as it doesn't let you
create values with wrong types; it can still cause segementation
faults in very special cases, but the only such example I know is when
you apply it to floats, not functions.)
Note that you cannot use hashtables, as the default hash function will
fail on functions, but you can use an association list with physical
equality.
Type theoretician answer:
What you would need to do that transparently inside the type system is
generic functions with dynamics.
But, for a limited number of types, you can simulate it by rolling out
your own dynamic type wrappers. This is rather verbose, and completely
unadapted to your purpose, but here it is.
type ('a,'b) t =
Val of 'a
| Int of (int,'b) t
| Bool of (bool,'b) t
| Fun of ('b->'a, 'b) t
| Copy of ('a,'a) t
type t' = (unit,unit) t
# let wrap_iii f : t' = Int(Copy(Fun(Fun(Val f)))) ;;
val wrap_iii : (int -> int -> int) -> t' = <fun>
# let wrap_ii_i f : t' = Int(Copy(Fun(Copy(Int(Fun(Val f)))))) ;;
val wrap_ii_i : ((int -> int) -> int) -> t' = <fun>
# let add = (+)
let add' = wrap_iii add
let sub = (-)
let sub' = wrap_iii sub ;;
val add : int -> int -> int = <fun>
val add' : t' = Int (Copy (Fun (Fun (Val <fun>))))
val sub : int -> int -> int = <fun>
val sub' : t' = Int (Copy (Fun (Fun (Val <fun>))))
let cmp = object (cmp)
method eq : 'a 'b. ('a,'b) t -> ('a,'b) t -> bool = fun f g ->
match f, g with
Val f, Val g -> f == g
| Int f, Int g -> cmp#eq f g
| Bool f, Bool g -> cmp#eq f g
| Fun f, Fun g -> cmp#eq f g
| Copy f, Copy g -> cmp#eq f g
| _ -> false
end
# cmp#eq add' add';;
- : bool = true
# cmp#eq add' sub';;
- : bool = false
Of course you must extend t with all the types that you want to use.
If you use types of arity more than 2 then you must add extra
parameters to t, and the equivalent of Copy for these extra positions.
Technically, t works like a small register machine, which is
sufficient since the number of type is fixed. GADTs would give you a
stack machine, but this wouldn't really help in this setting.
Jacques Garrigue
Jacques Garrigue
> I use NTFS, and I do not think it is a hardware problem.
>
> I also tried telling make to use 2 threads, i.e. "make -j 2", and then
> the compilation fails after a while. Therefor, I think the most probably
> cause is that not all dependencies are included in the Makefile.
This is not really relevant. Many Makefiles include lines like
target: dep1 dep2 dep3
where dep1, dep2 and dep3 are supposed to be run in that order.
With -j, make will run them in parallel, which breaks this kind of
Makefile.
But without -j the build works correctly, so you cannot say that the
Makefile is wrong, just that it doesn't support -j. Whether you use an
SMP or not will not change that.
Jacques Garrigue
Diego Olivier Fernandez Pons
> Note that you cannot use hashtables, as the default hash function will
> fail on functions, but you can use an association list with physical
> equality.
I dont understand why the hash function fails on functions. When I call
Hashtbl.hash : 'a -> int with a function I get an integer. Does it mean
the integer could change while the program is running ?
# Hashtbl.hash (fun x -> x + 1);;
- : int = 151020553
# Hashtbl.hash (fun x -> x + 2);;
- : int = 151020609
# Hashtbl.hash (fun x y -> x + y);;
- : int = 151020669
I had in mind a reduction of the search space based on the hash value and
an association list with physical equallity test on the functions that
have the same hash (collisions).
Diego Olivier