* make[1]: warning: Clock skew detected. Your build may be incomplete. @ 2006-09-06 13:36 Mattias Waldau 2006-09-06 15:15 ` [Caml-list] " skaller 2006-09-06 16:01 ` Igor Peshansky 0 siblings, 2 replies; 8+ messages in thread From: Mattias Waldau @ 2006-09-06 13:36 UTC (permalink / raw) To: caml-list 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Caml-list] make[1]: warning: Clock skew detected. Your build may be incomplete. 2006-09-06 13:36 make[1]: warning: Clock skew detected. Your build may be incomplete Mattias Waldau @ 2006-09-06 15:15 ` skaller 2006-09-06 16:01 ` Igor Peshansky 1 sibling, 0 replies; 8+ messages in thread From: skaller @ 2006-09-06 15:15 UTC (permalink / raw) To: Mattias Waldau; +Cc: caml-list On Wed, 2006-09-06 at 15:36 +0200, Mattias Waldau wrote: > 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Caml-list] make[1]: warning: Clock skew detected. Your build may be incomplete. 2006-09-06 13:36 make[1]: warning: Clock skew detected. Your build may be incomplete Mattias Waldau 2006-09-06 15:15 ` [Caml-list] " skaller @ 2006-09-06 16:01 ` Igor Peshansky 2006-09-06 17:19 ` Mattias Waldau 1 sibling, 1 reply; 8+ messages in thread From: Igor Peshansky @ 2006-09-06 16:01 UTC (permalink / raw) To: Mattias Waldau; +Cc: caml-list On Wed, 6 Sep 2006, Mattias Waldau wrote: > 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/ |\ _,,,---,,_ pechtcha@cs.nyu.edu | igor@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" ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Caml-list] make[1]: warning: Clock skew detected. Your build may be incomplete. 2006-09-06 16:01 ` Igor Peshansky @ 2006-09-06 17:19 ` Mattias Waldau 2006-09-06 17:50 ` Equality/Hashtable for functions (inline help feature) Diego Olivier Fernandez Pons 2006-09-07 0:23 ` [Caml-list] make[1]: warning: Clock skew detected. Your build may be incomplete Jacques Garrigue 0 siblings, 2 replies; 8+ messages in thread From: Mattias Waldau @ 2006-09-06 17:19 UTC (permalink / raw) To: caml-list 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. Anyone else using Markus Mottl's Ocamlmakefile on a dual-core? I can live with this, I am just curious. -- Mattias ^ permalink raw reply [flat|nested] 8+ messages in thread
* Equality/Hashtable for functions (inline help feature) 2006-09-06 17:19 ` Mattias Waldau @ 2006-09-06 17:50 ` Diego Olivier Fernandez Pons 2006-09-07 0:19 ` [Caml-list] " Jacques Garrigue 2006-09-07 0:23 ` [Caml-list] make[1]: warning: Clock skew detected. Your build may be incomplete Jacques Garrigue 1 sibling, 1 reply; 8+ messages in thread From: Diego Olivier Fernandez Pons @ 2006-09-06 17:50 UTC (permalink / raw) To: caml-list Bonjour, 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Caml-list] Equality/Hashtable for functions (inline help feature) 2006-09-06 17:50 ` Equality/Hashtable for functions (inline help feature) Diego Olivier Fernandez Pons @ 2006-09-07 0:19 ` Jacques Garrigue 2006-09-07 10:31 ` Diego Olivier Fernandez Pons 0 siblings, 1 reply; 8+ messages in thread From: Jacques Garrigue @ 2006-09-07 0:19 UTC (permalink / raw) To: diego-olivier.fernandez-pons, Diego.FERNANDEZ_PONS; +Cc: caml-list From: Diego Olivier Fernandez Pons <Diego.FERNANDEZ_PONS@etu.upmc.fr> > 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Caml-list] Equality/Hashtable for functions (inline help feature) 2006-09-07 0:19 ` [Caml-list] " Jacques Garrigue @ 2006-09-07 10:31 ` Diego Olivier Fernandez Pons 0 siblings, 0 replies; 8+ messages in thread From: Diego Olivier Fernandez Pons @ 2006-09-07 10:31 UTC (permalink / raw) To: Jacques Garrigue; +Cc: diego-olivier.fernandez-pons, caml-list Bonjour, > 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Caml-list] make[1]: warning: Clock skew detected. Your build may be incomplete. 2006-09-06 17:19 ` Mattias Waldau 2006-09-06 17:50 ` Equality/Hashtable for functions (inline help feature) Diego Olivier Fernandez Pons @ 2006-09-07 0:23 ` Jacques Garrigue 1 sibling, 0 replies; 8+ messages in thread From: Jacques Garrigue @ 2006-09-07 0:23 UTC (permalink / raw) To: mattias.waldau; +Cc: caml-list From: Mattias Waldau <mattias.waldau@abc.se> > 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2006-09-07 10:32 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2006-09-06 13:36 make[1]: warning: Clock skew detected. Your build may be incomplete Mattias Waldau 2006-09-06 15:15 ` [Caml-list] " skaller 2006-09-06 16:01 ` Igor Peshansky 2006-09-06 17:19 ` Mattias Waldau 2006-09-06 17:50 ` Equality/Hashtable for functions (inline help feature) Diego Olivier Fernandez Pons 2006-09-07 0:19 ` [Caml-list] " Jacques Garrigue 2006-09-07 10:31 ` Diego Olivier Fernandez Pons 2006-09-07 0:23 ` [Caml-list] make[1]: warning: Clock skew detected. Your build may be incomplete Jacques Garrigue
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox