Skip to content
Browse files


  • Loading branch information...
1 parent bc52535 commit 2075eba7281b51af21ce9b6de7023ca71a0af89d @zli committed Feb 3, 2011
Showing with 374 additions and 0 deletions.
  1. +374 −0 2011-02-03-irc.log
374 2011-02-03-irc.log
@@ -0,0 +1,374 @@
+00:38:13 <thelema_> is this commonly used by anyone: let mod_if b f x = if b then f x else x
+00:54:52 <mrvn> you mean let x = if something then change x else x in ...?
+01:41:59 <_habnabit> I feel like there's some fundamental inversion of logic I haven't quite gotten yet. If I'm trying to execute code only if an exception is /not/ raised, how could I do that?
+01:47:53 <alexyk> why does specifying a default value defeat polymorphism?
+01:53:50 <alexyk>
+01:54:20 <kaustuv_> _habnabit: what do you mean by 'exception is not raised'?
+01:54:45 <_habnabit> kaustuv_, if running some code doesn't raise an exception
+01:57:03 <kaustuv_> let _ = some code () in some_other_code ()
+01:57:23 <_habnabit> kaustuv_, ah
+01:57:52 <_habnabit> kaustuv_, but I also want to handle the exception if it /is/ raised
+01:58:04 <_habnabit> kaustuv_, but not if it's raised by some_other_code
+01:58:43 <kaustuv_> match try Some (some_code ()) with _ -> None with Some _ -> some_other_code () | None -> handle_exception ()
+01:59:12 <kaustuv_> Might need to wrap the ... in try ... with Some _ in parens
+01:59:18 <_habnabit> kaustuv_, awesome, thanks
+02:00:37 <kaustuv_> err, I meant the ... in match ... with Some _
+05:34:24 <alexyk> hey thelema_
+05:35:04 <alexyk> why does a default parameter restrict polymorphism?
+05:35:23 <mbac> isn't it obvious?
+05:35:28 <alexyk> is there a way to specify it and still be able to pass another type as in the no-default version?
+05:36:09 <alexyk> mbac: my parameter is any output function; if none is given, an Int.print should be used. But I might give a floatPrint.
+05:36:41 <alexyk> I try to specify the type of that function generally in the type declaration, which doesn't help.
+05:37:03 <mbac> oops, i misunderstood :)
+05:37:14 <alexyk> np
+05:38:02 <mbac> hmm, so what's the simplest case
+05:50:37 <flux> alpounet, I guess it's because ocaml cannot have one function have more than one signatures
+05:51:02 <flux> I've encountered the same issue
+05:59:52 <mbac> it doesn't have anything to do with optional arguments
+06:00:27 <mbac> which is peculiar
+06:00:48 <mbac> let show_table to_s xs = let to_s = match to_s with Some f -> f | None -> string_of_int in List.iter (fun x -> Printf.printf "%s\n" (to_s x)) xs
+06:00:52 <mbac> has the same problem
+06:01:29 <mbac> show_table None [1; 2; 3]; works but show_table string_of_float [1.; 2.; 3] gives the type error
+06:01:45 <mbac> er, show_table (Some string_of_float) [1.; 2.; 3.]
+06:02:48 <flux> well, it is the same as the optional argument, but implemented manually
+06:03:43 <flux> you need to ask yourself "what is the type of this value?" when reading through the code
+06:03:49 <flux> for example, what is the type of to_s?
+06:04:12 <flux> is it 'a -> string or int -> string? well, any 'a -> string doesn't fit int -> string, but int -> string does. therefore, it is int -> string.
+06:04:48 <mbac> right
+06:06:27 <mbac> i don't understand how val show_table : ('a -> string) -> 'a list -> unit is all that different from val show_table : ('a -> string) option -> 'a list -> unit
+06:08:37 <mbac> do you?
+06:10:13 <flux> you can write the latter function by replacing to_s with let to_s = match to_s with Some f -> f | None -> assert false in ..
+06:10:27 <flux> and those signatures indeed aren't all that different
+06:11:19 <flux> the thing is that your version binds the type of xs
+06:12:03 <mbac> well, should it?
+06:12:21 <mbac> isn't it wrong to do that, in this case?
+06:13:14 <flux> not at all, but that loses the polymorphicity
+06:14:44 <mbac> yes. that's the wrong part. :)
+06:24:29 <mbac> let value x = ignore (match x with Some x -> x | None -> 0) ;;
+06:24:35 <mbac> value (Some 0.) ;;
+06:24:44 <mbac> expresses the same phenomena
+06:30:09 <mbac> i guess binding an explicit type to any name inside of a function immediately collapses the possibility of parameterizing them
+11:14:00 <kaustuv> Wow, never seen this style of printing types before:
+11:14:00 <kaustuv> > Error: This expression has type t/1217 but an expression was expected of type 'a t/1040
+11:21:19 <mfp> kaustuv: is that some 3.12.1 pre-release version?
+12:11:10 <adrien> kaustuv: I see that in the topevel when I redefine a type but not the functions using that type
+12:12:05 <adrien> type t = { a : int };; let f t = t.a;; type t = { a : int };; let g (t : t) = f t
+12:12:07 <adrien> something like that
+12:12:33 <adrien> nope, works :P
+12:13:21 <flux> you need to paste them one-by-one
+12:13:26 <flux> everything after ;; is discarded
+12:13:30 <adrien> ok, if you paste it all at once, it works, but if you use each "sentence" separately, you get "Error: This expression has type t/1046 but an expression was expected of type t/1041"
+12:13:33 <flux> which I'm not sure if it's a bug or not :)
+12:14:11 <adrien> flux: oh, right, had probably never paste anything on one line, well, anything typed on irc on a single that worked on the first try ;-)
+12:57:33 <edwin> well thats still better than what I get with 3.11.2: "Error: This expression has type t but an expression was expected of type t"
+13:21:44 <kaustuv> "t" is not a good name for practically any type. I hope that with signature substitution we will gradually start to see it disappear from non-library code
+13:22:39 <thelema_> kaustuv: t is only good as Foo.t?
+13:24:49 <mrvn> don't open modules with type t :)
+13:32:31 <kaustuv> What would be truly awesome is if we could rename the abstract types in a module when importing it. Something like: open Set with 'a t := 'a set
+13:33:41 <kaustuv> well, Set is a bad example. open Buffer with type t := buffer
+13:34:12 <mrvn> open Buffer with type buffer = t rather
+13:34:42 <kaustuv> I'm using the analogy with signature substitution. I want all the ts replaced with buffers
+13:35:13 <mrvn> then signature substitutions are the wrong way around too.
+13:35:20 <mrvn> :)
+13:35:41 <kaustuv> Your opinion is objectively incorrect and you should feel bad for having it!
+13:35:41 <kaustuv> :)
+13:35:59 <mrvn> type new_name = old_name; let new_value = old_value :)
+13:36:20 <flux> I happend to think t is a great type name :)
+13:36:25 <flux> provided you have a single-type module
+13:36:29 <flux> or rather, single-main-type module
+13:36:36 <mrvn> nice and short.
+13:36:46 <mrvn> I would hate to have to type Buffer.buffer
+13:37:10 <flux> indeed
+13:37:30 <kaustuv> I would rather see an error message saying "x has type buffer when I was expecting it to have type fluffer", rather than "x has type t/1024 when I was expecting it to have type t/2048"
+13:38:11 <flux> how about ..has type Buffer.t.. ?
+13:38:21 <flux> because it does that, you know ;) - unless you open it, which I avoid
+13:38:49 <kaustuv> Right, the type printer is easily confused by open. I think open is a Good Thing.
+13:39:36 <flux> I've found open to be detrimental to reading code. it's more difficult to say where the symbols originate from.
+13:39:43 <flux> I suppose it's more of a tooling issue though
+13:40:10 <flux> I prefer project-wide or local module aliases
+13:40:28 <adrien> I often keep full "paths", I tend to do mostly "let sprintf = Printf.sprintf"
+13:40:54 <flux> for example let's say one has examples of eliom code
+13:41:01 <flux> with a bunch of opens in the end
+13:41:16 <flux> learning where to actually find the definitions can be a bit of work
+13:41:45 <flux> and then it also leads to prefixing record fields so that they are more open-compatible
+13:42:55 <kaustuv> For things like Lwt or even List and Printf, keeping the path is OK, but try writing Bigarray.Array1 a dozen times.
+13:43:22 <flux> for those I use aliases
+13:43:42 <adrien> same here: module A (* or Array) = Bigarray.Array1
+13:43:44 <flux> and preferably the same aliases for the whole project, ie. I have module with a few includes etc
+13:43:55 <adrien> well, I skipped half the syntax
+13:45:57 <kaustuv> I should probably know this, but do module aliases interact well with the inliner?
+13:46:43 <f[x]> "learning where to actually find the definitions can be a bit of work" <- compiler + editor does that for me
+13:47:16 <flux> f[x], ocamlspot works great, but less great on a web page :)
+13:47:29 <f[x]> -annot is enough
+13:47:44 <flux> annot tells function origination these days?
+13:47:48 <f[x]> web page with many many modules with long paths?
+13:48:01 <flux> simply browsing said eliom examples on the web
+13:48:22 <f[x]> -annot was doing that for ages iirc
+13:49:17 <f[x]> ok, but I find it pointless to optimize code to be readable on the web :)
+13:50:00 <flux> how about optimizing to be readable without relying on specific tools?-)
+13:50:04 <kaustuv> OK, -dlambda shows that module projections are inlined, but the module aliases still persist in the generated structure
+13:51:06 <f[x]> maybe
+13:51:52 <kaustuv> Also, there is a difference between reading finished code and debugging code in flux. When I'm simply exploring an idea, I have a very low tolerance for module bureaucracy. Sadly, this is the very code that the type checker often takes issue with.
+13:53:18 <flux> well, for me, using single-letter module aliases is sufficient, and avoids all those issues
+13:53:43 <flux> and it even lets me rename the alias later easily, if so so wish
+13:53:52 <mrvn> B.t is still less to type than buffer. :)
+13:54:29 <kaustuv> The point is I would write neither B.t nor buffer. The compiler can fill in types for me.
+13:55:55 <mrvn> unless you need to specify a signature somewhere
+13:56:10 <mrvn> or a type t = Buffer.t :)
+13:56:26 <alexyk> ok, a repeat from yesterday. Why does a default value bind a parameter to a specific type?
+13:57:51 <mrvn> because it is syntactic suggar for let printShowTable tex verbose = let verbose = match verbose with None -> false | _ -> verbose in ....
+13:58:10 <mrvn> because it is syntactic suggar for let printShowTable tex verbose = let verbose = match verbose with None -> false | Some v -> v in ....
+13:58:16 <alexyk> those are OK. I'm talking about printOne
+13:58:25 <mrvn> same thing.
+13:58:26 <flux> alexyk, it doesn't need to, btw: let foo ?(a=fun x->x) x = a x
+13:58:37 <alexyk> when I drop the default, I can pass in floatPrint
+13:58:39 <flux> but that's now what you want :)
+13:58:45 <flux> noT
+13:58:55 <kaustuv> alexyk: what type would you expect "printShowTable2 tex ~verbose floatTable name" to have?
+13:58:56 <mrvn> flux: that still sets the type to that of "fun x -> x". That is just polymorphic.
+13:59:13 <alexyk> if I specify default Int.print, I can only pass in ...-> int -> unit
+13:59:27 <alexyk> kaustuv: that won't typecheck
+13:59:32 <alexyk> against Int.print
+13:59:33 <kaustuv> alexyk: why not?
+13:59:58 <kaustuv> (note, typechecking happens by instantiating type variables, not by looking up function definitions)
+14:00:09 <alexyk> kaustuv: because it will invole printTable which will use Int.print to print every element of floatTable
+14:00:21 <mrvn> Because the "None -> Int.print" clause determines the type.
+14:00:35 <alexyk> aha
+14:01:06 <alexyk> so default parameters screw up polymorphism
+14:01:15 <alexyk> this is a deficiency
+14:01:17 <kaustuv> No, they don't
+14:01:24 <kaustuv> You are misunderstanding what polymorphism is
+14:01:25 <mrvn> alexyk: no. They just are syntactic suggar and you have to look at the code they represent.
+14:01:39 <alexyk> we disagree about the sugar
+14:01:47 <alexyk> I consider a default as a mere convenience
+14:01:54 <alexyk> it must not affect the typing
+14:01:59 <mrvn> think of it as a makro that is expanded before the compiler infers types.
+14:02:14 <alexyk> Int.print satisfies the general requirement of a more general type of printOne I explicitly specify
+14:02:21 <kaustuv> A default must *always* be an acceptable parameter, and therefore must determine the type.
+14:02:35 <kaustuv> Hence, why Int.print is not an acceptable parameter for floatTable
+14:02:40 <alexyk> kaustuv: default will then always restrict the type
+14:03:24 <mrvn> alexyk: yes
+14:03:35 <alexyk> hmm
+14:04:11 <alexyk> kaustuv: I see your point, but it's jumping the shark -- I'd rather it to consider the default last and not use it in inference at least when I *give* the type above
+14:04:22 <mrvn> alexyk: The problem is that the type would differ depending on wether you pass the extra arg or not.
+14:04:56 <mrvn> alexyk: or worse, the optional arg could be come not optional due to the first arg you apply.
+14:05:02 <kaustuv> alexyk: The point is that the typechecker *does not know* how the function is defined. Imagine if it came from some code for which you don't have the source. What type signature would you give to your more relaxed notion of default arguments?
+14:05:44 <flux> alexyk, internally I believe code like let foo ?(a=string_of_int) b = b a is expanded into something in effect let foo a b = let a'val = match a with None -> string_of_int | Some a in b a
+14:06:01 <flux> alexyk, can you tell what the type of the signature of the latter function should be?
+14:06:25 <alexyk> flux: which latter?
+14:06:34 <flux> let foo a b = let a'val = match a with None -> string_of_int | Some a in b a'val
+14:06:46 <flux> argh
+14:06:51 <mrvn> foo: int -> string | ('a -> string) -> 'a -> string :))
+14:07:16 <flux> let foo a b = let v = match a with None -> string_of_int | Some a -> a in b v
+14:07:53 <mrvn> flux: if you look at the asm that produces that is exactly what the compiler makes of optional args
+14:08:13 <alexyk> flux: value foo : option (int -> string) -> ((int -> string) -> 'a) -> 'a
+14:08:17 <alexyk> :)
+14:08:27 <alexyk> (in Batteries)
+14:08:36 <flux> alexyk, but you would want it to be.. ?
+14:08:43 <thelema_> alexyk: try duplicating the body of your function, one for each path
+14:10:12 <alexyk> ok I see. So the default is much more than a default. It's used in expansion and typecheck. I'd prefer the explicit type I give to dominate and make the default secondary convenience, to be substituted into a defined type if given...
+14:10:13 <thelema_> and I think it's time to get rid of the camlp4 bug by releasing batteries 1.3... in about 8 hours, after work
+14:10:26 <mrvn> It's time to get a hair cut.
+14:10:29 <mrvn> now.
+14:10:45 <alexyk> mrvn: programmers don't do haircuts!
+14:11:34 <alexyk> thelema_: I like Battieries types! They are postfix and read well :)
+14:13:12 <kaustuv> alexyk: the "explicit type" you give is not polymorphic enough. You need to explicitly mark the polymorphic variables (not doable in OCaml < 3.12).
+14:13:48 <alexyk> kaustuv: I am in 3.12! How'd I be explicit enough?
+14:13:58 <kaustuv> let printShowTable2: 'a 'b 'c. tex -> ?verbose:bool -> ~printOne:('a BatInnerIO.output -> 'b -> unit) -> 'c list list -> string -> unit =
+14:14:06 <kaustuv> (and it won't typecheck then)
+14:14:22 <alexyk> aha
+14:15:09 <kaustuv> btw, you shouldn't use ~foo:t in type signatures as that is deprecated. Just say foo:t
+14:15:18 <kaustuv> (IIRC)
+14:25:39 <alexyk> kaustuv: trying to compile in 3.12 gives error: let printShowTable2: 'a 'b 'c. tex -> ?verbose:bool -> Error: Parse error: [ctyp] expected after "->" (in [ctyp]), the last -> -- why?
+14:28:04 <alexyk> kaustuv: I oscillated, now am back :)
+14:37:05 <kaustuv> alexyk: that sounds like a camlp4 error. The syntax I wrote was native ocaml.
+14:38:47 <kaustuv> This works for me: let f : 'a 'b. 'a -> 'b = fun 1 -> failwith "undefinable" ;;
+14:38:47 <kaustuv> (where "worrks" means type error, not syntax error)
+14:39:37 <alexyk> yep
+14:39:54 <kaustuv> Ah, the ~foo:t form is required in revised syntax. Are you using revised syntax perchance?
+14:40:11 <kaustuv> You must be since your option type was prefix instead of postfix
+14:40:12 <alexyk> kaustuv: I am in Batteries, nothing else
+14:40:27 <alexyk> Batteries prints types in postfix
+14:40:33 <alexyk> but takes them in prefix
+14:40:42 <alexyk> until thelema fixes it tonight :)
+14:41:15 <kaustuv> No, postfix is OCaml's default. Prefix is only in revised syntax, I believe, which means you must be using a syntax extension.
+14:49:22 <kaustuv> thelema_: before releasing 1.3, can you merge my change to BatHeap that switches insert and add so that add has the same semantics as in Set, Map, etc.?
+14:50:23 <thelema_> kaustuv: no problem
+15:47:49 <jlenormand> I have an omake question
+15:47:57 <jlenormand> how do I get omake to print out every command that it runs?
+15:58:14 <kaustuv> --no-S ?
+16:03:41 <hcarty> alexyk: Batteries should have that toplevel printing error fixed in git
+16:14:52 <jlenormand> isn't --no-S the default?
+16:15:39 <jlenormand> -s "Never not [sic] print commands as they are executed"
+17:08:27 <kaustuv_> jlenormand: My omake --help says that -S is the default...
+19:10:49 <_habnabit> Is there a function application operator like haskell's $ ?
+19:11:05 <_habnabit> Basically 'stop interpreting things as arguments and apply this function'
+19:26:03 <hcarty> _habnabit: Nothing pre-defined
+19:29:26 <thelema_> _habnabit: let (<|) f x = f x
+19:29:48 <thelema_> it doesn't have the right associativity, but it works often enough
+19:30:45 <hcarty> Some code uses ( & ) for that
+19:31:13 <hcarty> But that stops working with JoCaml
+21:45:11 <kaustuv> thelema_: the pre-aaa era TODO file still in the root of the batteries source tree is kind of misleading. As github has become the semi official issue tracker, maybe it ought to be removed?
+21:45:43 <thelema_> kaustuv: agreed
+21:46:21 <thelema_> pushed
+21:53:51 <elehack> anyone know what OCaml machinery leads to a process terminating with status code 127 w/o any output?
+21:54:15 <thelema_> elehack: that's an impressive error. Never got that one.
+21:54:45 <elehack> I've wrapped the main code in a try...with that exits with code 5, so it doesn't seem to be an exception thing...
+21:55:03 <elehack> and if it were a segfault, then the parent should see a signal, not an exit status...
+21:55:07 <thelema_> huh, has some exit 127's
+21:55:32 <elehack> ahh.
+21:55:37 <elehack> perhaps it isn't in my subprocess then...
+21:55:58 <elehack> (the parent is doing fork-exec)
+21:56:01 <thelema_> seems to be the exit code of a failed create process
+21:56:18 <elehack> interesting.
+21:56:23 <elehack> thanks for digging that up.
+21:56:29 <thelema_> yup, lots of "exit 127" in error handlers around forks and execvs
+21:56:29 <elehack> I wish I knew *why* it was failing...
+21:56:50 <ygrek> man bash?
+21:57:00 <thelema_> you could hack your unix to backtrace instead of exit 127
+21:57:18 <elehack> I could... wouldn't be the first time I've patched OCaml.
+21:58:21 <ygrek> Sys.command "qqq" will have return code 127
+21:58:44 <thelema_> path problems?
+21:59:33 <elehack> possibly.
+21:59:44 <elehack> however, it successfully runs the program the first few hundred times.
+21:59:55 <thelema_> lol
+21:59:59 <elehack> and then fails without warning or explanation.
+22:00:07 <thelema_> ulimit -a
+22:00:45 <elehack> no particularly onerous looking limits.
+22:00:48 <elehack> 71K processes
+22:01:08 <elehack> 1024 file descriptors, but I believe that's per-process, not per-process-tree.
+22:01:15 <elehack> unless I'm leaving a file descriptor open somehow.
+22:03:33 <elehack> ahh, here's the problem.
+22:03:36 <elehack> I think.
+22:03:45 <elehack> BatUnix.in_channel_of_descr sets autoclose to false.
+22:04:00 <elehack> so I'm leaking a file descriptor every fork.
+22:04:11 <elehack> not sure why it shows up in the child process and not the parent, but that's probably the problem.
+22:04:34 <kaustuv> create_process calls pipe(2)
+22:04:43 <elehack> that'd do it.
+22:05:24 <elehack> I wonder why this machinery fails rather than raising Unix_error?
+22:05:54 <thelema_> maybe *very* old code
+22:07:56 <kaustuv> well, the exec() calls are in the child process, and there is no alternative but to exit if that call fails
+22:08:24 <elehack> why can't the child die with an exception?
+22:09:13 <kaustuv> It does exactly that. The exception just isn't propagated to the parent because there is no facility for that
+22:09:54 <elehack> yes, but I would expect the runtime in the child process to print the standard "unhandled exception" message before exiting
+22:12:59 <elehack> I suppose that would somewhat break the abstraction of create_process by allowing parent exception handlers to run in a child process on failed exec.
+22:14:30 <elehack> Now that I'm (hopefully) no longer leaking file descriptors, maybe it will finish now.
+22:14:34 <elehack> thanks for helping track this down.
+22:14:45 <thelema_> shallow many eyes
+22:15:11 <elehack> thelema_: is there a particular reason BatUnix.in_channel_of_descr sets autoclose to false? near as I can tell tracing the C sources for stdlib's unix, the standard version does auto-close the FD.
+22:15:18 <kaustuv> elehack: the child doesn't print a message because its stderr might not be the same as the parent's stderr, so there is no guarantee that the message ever gets seen
+22:15:19 <elehack> out_channel_of_descr leaves autoclose alone
+22:15:25 <elehack> kaustuv: true.
+22:15:54 <thelema_> elehack: no reason I know of.
+22:16:06 <elehack> thelema_: OK, then I'll push a patch to fix that sometime here.
+22:16:12 <thelema_> elehack: wouldn't hurt to git blame that code to see its history, just in case
+22:16:34 <thelema_> the patch is welcome anyway
+22:17:02 <agarwal1975> Hi. Just posted to the batteries-devel list, but I'll ask here too. Getting a build error with batteries-included
+22:17:54 <agarwal1975> Makefile determines camomile version by running ocamlfind list | grep camomile | grep -o "[0-9\.]*"
+22:18:04 <thelema_> agarwal1975: can you update - I changed that code just recently
+22:18:09 <kaustuv> agarwal1975: the devel version of batteries requires camomile 0.8+
+22:18:17 <kaustuv> Or am I wrong?
+22:18:33 <thelema_> kaustuv: I don't think so - it autodetects all the way back to 0.7
+22:19:01 <thelema_> something is wierd with his grep, but f[x] pointed out a way to call ocamlfind to get the version directly instead of hacking it out of the response
+22:19:16 <agarwal1975> well, godi-camomile is only up to 0.7.1. Guess i can install camomile manually too.
+22:19:20 <thelema_> fixed in commit 9c03c47f
+22:19:49 <thelema_> 29 hours ago
+22:19:49 <agarwal1975> However, is that the issue. Makefile does ocamlfind list | grep camomile | grep -o "[0-9\.]*", which in fact returns the empty string.
+22:20:20 <thelema_> well, the new code will run 'ocamlfind query -format %v camomile' which should return the version directly
+22:20:41 <thelema_> agarwal1975: what os are you running?
+22:21:00 <agarwal1975> Mac OS X.
+22:21:15 <thelema_> apparently grep -o does something different there.
+22:21:24 <thelema_> can you update to latest git?
+22:21:51 <kaustuv> I am pretty sure \ is not needed inside [] in posix regexp
+22:22:06 <agarwal1975> I tried it on a redhat also. Same behavior.
+22:22:31 <thelema_> ok, I guess I have a particularly friendly grep under ubuntu
+22:22:33 <agarwal1975> Also, why does it work when installing via godi? Isn't the godi package using the same Makefile.
+22:22:48 <kaustuv> On a linux, I think grep needs -E in addition to -o.
+22:22:54 <thelema_> the godi package is quite old, and doesn't have any auto-detection
+22:22:57 <kaustuv> (Anyway, the issue is fixed by tossing grep out)
+22:23:07 <thelema_> yes, I'm happy to toss grep out
+22:23:24 <agarwal1975> kaustuv: which commit is that in. I just pulled from master and grep is still there.
+22:23:42 <elehack> agarwal1975: if you want a newer Batteries on GODI, set the GODI_BATTERIES_VCS_CHECKOUT option to yes
+22:23:55 <kaustuv> agarwal1975: <thelema_> fixed in commit 9c03c47f
+22:24:11 <thelema_> agarwal1975: where are you pulling from?
+22:24:38 <kaustuv> agarwal1975: apparently in branch release-1.3, not master
+22:24:49 <thelema_> oops
+22:24:51 <agarwal1975>
+22:24:58 <thelema_> well, it'll get merged back into master soon enough
+22:26:51 <thelema_> can anyone verify that ocaml removes [if false then ... ] from executable?
+22:27:06 <agarwal1975> I'm not a git pro yet. Is it okay for me to just merge in commit 9c03c47f? Or should I be tracking the release-1.3 branch instead of master?
+22:27:18 <thelema_> agarwal1975: git co release-1.3
+22:27:41 <thelema_> but yes, it's okay for you to cherry pick that commit, and probably even merge release-1.3 into master
+22:29:01 <agarwal1975> Do you know how to change the remote branch being tracked by a local branch?
+22:29:20 <kaustuv> thelema_: ocamlopt -dcmm confirms that [if false then e] is removed
+22:29:24 <agarwal1975> not critical, just wondering.
+22:29:42 <thelema_> kaustuv: thanks, that's important for what I'm just doing
+22:29:49 <thelema_> agarwal1975: edit your .git/config file
+22:30:25 <agarwal1975> perfect. thanks!
+22:31:06 <kaustuv> thelema_: note, the bytecode compiler doesn't go through the Cmm phase, so the bytecodes are not removed (checked with ocamlc -dinstr)
+22:31:09 <elehack> thelema_: I found the offending commit (it's from Feb. 2009, with some added stuff for cleaning up inherited IO channels), but don't see a particular reason for changing the autoclose setting.
+22:31:17 <elehack> should the fix go on the release-1.3 or master branch?
+22:32:13 <thelema_> elehack: put it in 1.3, if someone complains, we'll fix it in 2.0. I don't see much harm in autoclosing extra
+22:32:37 <thelema_> kaustuv: got it. Luckily I'm not doing my time critical code in bytecode
+22:35:08 <kaustuv> Why on earth is the autoclose knob exposed? When does it make sense to keep an input or output open when its underlying channel is closed?
+22:36:01 <elehack> kaustuv: the issue is when you wrap a file descriptor in a channel. when you close the channel, does it close the underlying file descriptor?
+22:37:54 <kaustuv> depends on what owns the fd, but if multiple higher abstractions are sharing an fd then the code is doing something bizarre
+22:39:45 <elehack> I agree. Not sure what the use case for non-autoclosing channels is (thus the default is autoclosing).
+22:41:33 <kaustuv> also, unless I am reading the docs wrong, the meaning of ~autoclose is that if the underlying thing closes then close self, not if close self then close underlying thing. (The latter seems to be the ~cleanup parameter)
+22:41:36 <elehack> patch pushed to release-1.3.
+22:42:22 <elehack> kaustuv: hrm, interesting.
+22:42:26 <elehack> I might have just patched the wrong thing then.
+22:42:44 <elehack> in which case I still have a bug on my hands.
+22:43:26 <kaustuv> do double check my interpretation with what the actual code does
+22:43:29 * elehack should read better.
+22:43:55 <elehack> I can try to, but the IO logic is a maze of twisty passages all alike sometimes.
+22:45:19 <agarwal1975> now compiling release-1.3 but get: + ocamlfind ocamlopt -shared -linkall -package camomile,num,str -o src/batteries_uni.cmxs src/batteries_uni.cmxa
+22:45:20 <agarwal1975> ld: warning: -read_only_relocs cannot be used with x86_64
+22:45:20 <agarwal1975> ld: codegen problem, can't use rel32 to external symbol _caml_negf_mask in .L101 from src/batteries_uni.a(batFloat.o)
+22:45:41 <thelema_> agarwal1975: really? that's an interesting one.
+22:45:47 <agarwal1975> is it maybe because I installed camomile thru godi?
+22:46:03 <thelema_> unlikely
+22:46:29 <elehack> agarwal1975: it's a known Mac issue.
+22:46:43 <elehack> turn off native shared libraries (there's a Make flag, and a GODI option as well)
+22:46:55 <kaustuv> agarwal1975:
+22:47:47 <agarwal1975> that did it!
+22:48:17 <agarwal1975> I've never had to set this flag via godi.
+22:48:34 <elehack> kaustuv: looks like your interpretation is correct, and my patch is incorrect.
+22:48:41 <elehack> which means I still have a bug.
+22:50:47 <kaustuv> release notes for 3.11.2 state (in fixed bugs section)
+22:50:48 <kaustuv> > - PR#4867, PR#4760: ocamlopt -shared fails on Mac OS X 64bit
+22:50:48 <kaustuv> Do you have an OCaml older than that?
+22:51:55 <agarwal1975> that could be it. I had started using ocaml 3.12, but reverted to 3.11 just for batteries devel.
+22:52:18 * elehack has now pushed a reversion to the previous autoclose change
+22:52:39 <thelema_> agarwal1975: batteries works with 3.12
+22:53:00 <agarwal1975> is that recommended? I'm assuming I should test my batteries contributions against 3.11 since we're not yet officially supporting 3.12.
+22:53:37 <thelema_> test against 3.12. Just because I'm still using 3.11 (for some unknown reason) doesn't mean 3.12 isn't fully supported
+22:53:53 <agarwal1975> ok, but is it legitimate to use new 3.12 features?
+22:54:00 <thelema_> no
+22:54:24 <thelema_> not for a while - there's still a lot of people out there with 3.11.
+22:54:28 <kaustuv> is there a sunset clause for <= 3.11 support?
+22:54:36 <kaustuv> Like say circa 2015?
+22:55:07 <thelema_> if the next stable ubuntu includes 3.12, we can drop 3.11 support
+22:55:17 <thelema_> err, not stable, LTE
+22:55:29 <adrien> LTS* ;-)
+22:55:31 <thelema_> LTS? hwatever the long term support thins
+22:55:38 <thelema_> :)
+22:57:43 <elehack> I expect it will - it isn't due for another year.
+22:57:52 <elehack> RHEL6, on the other hand...
+22:58:29 * elehack is not proposing that we maintain 3.11 compatibility for the lifetime of RHEL6.
+22:59:41 <kaustuv> Maybe with 2.0 you can be justified in breaking backwards compatibility with both earlier versions of batteries and earlier versions of ocaml
+23:00:46 <elehack> that's what I'm thinking.
+23:01:00 <elehack> esp. if first-class modules let us clean up some APIs (which I think they will)
+23:01:38 <thelema_> that would be a good time to do it. Although I don't want to artificially couple backwards-incompatible changes with ocaml version expiration
+23:02:21 <thelema_> I hope those two go together, but I don't plan on making 2.0 come early or late just so the two co-incide
+23:03:17 <elehack> thelema_: agreed, it shouldn't set schedule. we can always release another bug-fix release or two of the 1.x series for people who can't upgrade OCaml, even after 2.0 is released.
+23:03:50 <thelema_> that's a good solution
+23:03:57 <elehack> in fact, it may be worthwhile to see if we can time things to have 2.0 ready before the next LTS freeze.
+23:04:59 <elehack> but that probably shouldn't be a very hard deadline - better to have an awesome 2.0 than a 2.0 in Ubuntu 12.04.
+23:06:37 <elehack> And it's time to go home... tomorrow will tell whether adding autoclose will fix my bug or not.
+23:26:57 <hcarty> Does OCaml ever treat 0.0 as distinct from (-0.0)?
+23:27:04 <hcarty> Aside from classify_float
+23:42:35 <kaustuv> hcarty: Marshal.to_string 0.0 [] = Marshal.to_string (-0.0) [] ==> false
+23:43:42 <kaustuv> Heck, string_of_float 0.0 <> string_of_float (-0.0)
+23:47:23 <kaustuv> is there an implementation of IEEE 754 decimal floating points in ocaml?
+23:59:52 <hcarty> kaustuv: Ah, fair point. Thanks.

0 comments on commit 2075eba

Please sign in to comment.
Something went wrong with that request. Please try again.