Skip to content

Comparing changes

Choose two branches to see what’s changed or to start a new pull request. If you need to, you can also .

Open a pull request

Create a new pull request by comparing changes across two branches. If you need to, you can also .
  • 2 commits
  • 2 files changed
  • 0 commit comments
  • 1 contributor
Showing with 564 additions and 0 deletions.
  1. +545 −0 _posts/2012-04-12-irc.log
  2. +19 −0 _posts/2012-04-12-twt.log
545 _posts/2012-04-12-irc.log
@@ -0,0 +1,545 @@
+title: 2012/04/12/IRC
+layout: irc
+{% highlight irc %}
+00:30:21 <everyonemines> mrvn: php programmers say: We only have a vulnerability found every couple weeks, php is fine. C++ programmers say: our program only crashes every couple hours, C++ is fine.
+00:32:01 <everyonemines> java programmers say: verbosity doesn't matter if you use eclipse, java is fine
+00:32:49 <everyonemines> but seriously, php makes people feel like they're getting stuff done
+00:32:53 <everyonemines> and ocaml frustrates people
+00:33:15 <_habnabit> does it? I'd say it's the opposite for me
+00:33:21 <everyonemines> I've seen it. it's not "worse is better" it's
+00:33:34 <everyonemines> if your system is designed by a noob programmer
+00:33:47 <everyonemines> then noob programmers will sometimes find it more intuitive
+00:34:12 <everyonemines> that's my explanation for php
+00:34:37 <everyonemines> from a business perspective, people use php because there are php developers
+00:34:48 <everyonemines> they don't even consider varying programmer quality across languages
+00:35:01 <Drakken> Frustration with OCaml is temporary; with PHP, it's built in.
+00:35:06 <everyonemines> or security issues
+00:35:16 <everyonemines> they say, there are php programmers, other companies use php
+00:36:10 <everyonemines> Drakken: You have to admit that it's noob unfriendly. But what's weird to me is the success of haskell.
+00:36:32 <Drakken> Noob's shouldn't do professional software development.
+00:36:37 <everyonemines> maybe it's "look at how smart I am" with haskell
+00:36:41 <everyonemines> that causes people to write about it
+00:36:46 <everyonemines> that causes more people to look into it
+00:36:49 <everyonemines> beats me
+00:36:50 <Drakken> Haskell is like veganism.
+00:37:02 <everyonemines> and I like a good steak
+00:37:11 <everyonemines> but preferably grass fed
+00:37:19 <Drakken> OCaml is vegitarianism, and Haskell is veganism.
+00:37:58 <Drakken> OCaml/vegitarianism used to be cool in certain circles, but now they're not extreme enough. Only Haskell/veganism are considered hip.
+00:38:29 <Drakken> :)
+00:38:40 <everyonemines> whereas I just avoid fast food and get exercise
+00:38:47 <everyonemines> and cook balanced meals
+00:38:53 <everyonemines> this metaphor is working out pretty well
+00:39:41 <Drakken> Weeding out noobs is a good thing.
+00:40:35 <Drakken> Employers complain about all the dummies who apply for jobs, but they could weed them out easily by making them explain things like pointers, closures, and HOFs.
+00:41:22 <Drakken> Most of the people who shouldn't be programming wouldn't even apply if they know they'll be asked hard questions.
+00:41:44 <Drakken> And some of the people who have be driven away by languages like PHP would come back.
+00:41:55 <Drakken> BEEN driven
+00:46:35 <Drakken> OCaml strikes a good balance between safety and convenience.
+00:47:07 <Drakken> I might like to tweak it a little one way or another, but it's a great tool for large-scale development.
+00:50:20 <everyonemines> how would you tweak it exactly
+00:51:26 <everyonemines> personally i think some integrated build handling would be good
+01:00:50 <Drakken> It doesn't matter. I would design a whole new language if I could, but for now I just want to avoid mainstream languages.
+01:01:39 <_habnabit> why
+01:04:20 <Drakken> why what?
+01:05:09 <_habnabit> why avoid 'mainstream languages'
+01:06:30 <vext01> hipster?
+01:06:55 <Drakken> That's it. I'm just too l33t :)
+01:08:25 <vext01> so i just started learning ocaml today
+01:08:53 <vext01> i wrote a simple tree traversal
+01:08:56 <vext01>
+01:09:15 <vext01> on line 23, why do I have to construct a new leaf?
+01:09:25 <vext01> or.. why was the Leaf unpacked to int
+01:09:51 <_habnabit> it was never a leaf. it's of type 'a
+01:10:02 <vext01> i just saw it after I hit enter
+01:10:07 <vext01> my bad
+01:12:23 <vext01> i was also wondering why record exists when you can probably achieve what you need with cartesian product
+01:12:33 <vext01> is it just for naming of elements?
+01:12:35 <_habnabit> 'record' ?
+01:12:48 <vext01>
+01:12:49 <vext01> let p = { name = "John"; info = 23 };;
+01:13:01 <_habnabit> and what do you mean by 'cartesian product' ?
+01:13:29 <vext01> tree * int * tree
+01:13:35 <vext01> ^ is that not what this represents?
+01:13:42 <_habnabit> well. that's a tuple. kind of
+01:14:03 <_habnabit> 'a * 'b is the type of a tuple with two elements
+01:14:24 <_habnabit> also as soon as they get beyond two elements, they become _very_ difficult to reason about
+01:14:38 <_habnabit> names make that easier
+01:14:39 <vext01> for example?
+01:15:03 <_habnabit> you have to remember what position means what, since there's not a codified name for each position
+01:15:17 <vext01> that was my original question ;)
+01:15:27 <vext01> 02:19 < vext01> is it just for naming of elements?
+01:15:41 <_habnabit> well, no
+01:15:54 <Drakken> but mostly
+01:16:08 <_habnabit> records also support 'mutable'
+01:16:27 <Drakken> there's also a convenient syntax where you can write { foo with bar = x }
+01:16:29 <_habnabit> oh, and updating a record is _much_ easier
+01:16:30 <_habnabit> yes
+01:16:50 <vext01> i see
+01:18:52 <mrvn> But that is all syntactic suggar. The memory representation for tuples and records is the same.
+01:19:07 <_habnabit> is it ?
+01:19:30 <vext01> how comes a record does not get a constructor?
+01:19:39 <vext01> like other types
+01:19:50 <everyonemines> has somebody already done k-means in ocaml
+01:19:50 <_habnabit> what would it do?
+01:19:55 <everyonemines> or do i need to port a c version
+01:20:02 <mrvn> records, tuples and variant types with only one constructor are the same in memory
+01:20:27 <vext01> _habnabit: suppose my tree could hold records too
+01:20:32 <mrvn> vext01: the lables already make the type inference happy. no need to a constructor.
+01:20:36 <vext01> type tree = Leaf of int | Node of tree * int * tree | ???;;
+01:20:49 <_habnabit> vext01, you have to define the record type separately
+01:20:50 <vext01> what do you put in ??? if you have a record called 'jim'
+01:21:08 <_habnabit> vext01, type jim = {x: int; y: int} type tree = Jim of jim
+01:21:33 <mrvn> vext01: type 'a tree = Leaf of 'a | Node of tree * 'a * tree, type my_tree = jim tree
+01:22:01 <Drakken> I would prefer explicit constructors.
+01:22:09 <vext01> i find this confusing
+01:22:21 <mrvn> Drakken: then use them instead of records
+01:22:21 <_habnabit> what's confusing about it?
+01:22:42 <vext01> there are two ways to instantiate things?
+01:22:50 <vext01> er
+01:22:53 <vext01> define types
+01:22:57 <mrvn> vext01: no
+01:23:18 <Drakken> I mean I would prefer field labels that don't conflict, and that requires specifying the type when creating a record.
+01:23:37 <Drakken> and in pattern matching.
+01:23:49 <vext01> mrvn: you must forgive me, i come from C land
+01:24:02 <mrvn> Drakken: there is a branch that adds lables for fields in variant types.
+01:25:37 <vext01> what I cam confused about is that you define a record type
+01:25:50 <vext01> then you cant directtly refer to it in another type?
+01:25:53 <vext01> or...
+01:26:12 <mrvn> vext01: sure you can
+01:26:12 <Drakken> vext01 what do you want to do with it?
+01:26:20 <vext01> hang on im just playing
+01:26:51 <vext01> yeh ok
+01:27:01 <vext01> so types are a little different to what I am used to
+01:27:16 <vext01> you define a class of types
+01:27:21 <vext01> so it seems?
+01:27:25 <Drakken> the main difference is variant types.
+01:27:41 <vext01> type xxx = A of int | B of string;;
+01:27:41 <mrvn> vext01: the only difference is that you can't pre-declare a type as in "struct foo;"
+01:28:00 <vext01> ^ here i define a type and two constructors
+01:28:04 <Drakken> You can defined Node of 'a*'a and Leaf of 'a to have the same type.
+01:28:36 <Drakken> xxx is a way to fake dynamic typing.
+01:29:08 <mrvn> vext01: that is just a struct { enum { A, B } kind; union { int i; char *str;} }
+01:29:14 <mrvn> vext01: but safe
+01:29:57 <vext01> yeh
+01:30:07 <Drakken> C unions use a constant amount of space.
+01:30:17 <Drakken> For all variants
+01:30:23 <mrvn> Drakken: details, tsss
+01:30:35 <vext01> its different, i can live with it
+01:31:00 <vext01> its reminiscent of bnf
+01:31:12 <Drakken> right
+01:31:18 <mrvn> vext01: you will encounter variant types all over the place. probably the most used thing in ocaml.
+01:31:34 <Drakken> also right
+01:31:37 <Drakken> :)
+01:32:12 <vext01> have you guys read or skimmed the book "practical ocaml"?
+01:32:36 <Drakken> I learned from the Inria manual.
+01:33:54 <everyonemines> i learned from the module reference
+01:33:56 <everyonemines> and the toplevel
+01:34:19 <vext01> well yah, im finding this easier than the book
+01:34:54 <everyonemines> read some ocaml code from somebody else
+01:35:03 <everyonemines> maybe stuff in batteries
+01:35:33 <vext01> i briefly looked at batteries
+01:35:57 <Drakken> vext01 xxx is a _single_ type that comes in two flavors. Each flavor (variant) defines a class of _values_
+01:37:16 <vext01> understood
+01:37:39 <vext01> is there something for vim+ocaml?
+01:37:42 <vext01> lots for emacs
+05:01:53 <flux> mrvn, indeed. actually what I've thought of earlier were the 3d fractals Povray can draw, but I suppose marching cubes is the standard solution for that.
+06:44:00 <adrien> morning
+07:46:39 <flux> pretty interesting stuff:
+07:46:51 <flux> (generalized exception-like open variants)
+07:47:09 <flux> especially the ability to define them in a polymorphic fashion seems interesting
+07:53:44 <flux> also pretty neat how the downcasting example works at the end
+07:55:31 <Drakken> What does "sites" mean on google?
+07:57:44 <adrien> user websites; mostly free-of-charge hosting
+08:47:34 <Anarchos> hi eikke
+09:02:22 <Anarchos> hello silver
+09:02:59 <adrien> you've scared him! ='(
+09:03:38 <Anarchos> adrien: i didn't speak about my first order verifier :)
+09:05:53 <adrien> hahaha
+09:06:02 <adrien> by the way, I have to leave :P
+09:07:36 <Anarchos> adrien: no problem i am at work anyway so not so much time to speak
+09:07:49 <adrien> heh :-)
+10:01:50 <eikke> is there any way to return a functor from a function?
+10:02:47 <adrien> should be fine using first-class modules, I _think_
+10:03:03 <flux> but are functors first class as well?
+10:03:19 <eikke> I thought so as well, but fighting syntax (or looking for something impossible)
+10:05:22 <adrien> can you apply the functor earlier in your code so you return a module and not the functor?
+10:05:44 <adrien> take the module which will be the argument as an argument to the function that you currently want to return a functor?
+10:06:05 <adrien> (no need to thank me for this exercise in contrived sentences :-) )
+10:09:33 <ousado> especially the last questionmark is puzzling :)
+10:09:33 <eikke> no, I cant work with the applied functor
+10:09:50 <Anarchos> eikke: it seems a little weird to return a functor from a function ...
+10:11:36 <eikke> why would it?
+10:15:27 <Anarchos> functions are values in lambda calcul, functors are natural transformations in category theory, so a more abstract level
+10:16:17 <Lor> you can't return a functor, but you can return a function from modules to modules.
+10:16:23 <eikke> adrien: your solution (inversing things) is not possible either :(
+10:16:52 <eikke> its possible, but it would introduce other issues :)
+10:16:58 <Lor> As long as you don't need applicative functors that should be okay.
+10:17:10 <adrien> maybe you can explain what is your high-level goal, what you are trying to achieve
+10:17:20 <adrien> and someone will come up with a solution
+10:17:35 <eikke> I intend to write a long blogpost about it, but will try to summarize
+10:19:18 <eikke> all code is at
+10:19:46 <eikke> is an implementation of a sort-of b-tree, which works on top of backing storage
+10:20:04 <eikke> we have several serialization systems for this storage, in and
+10:20:28 <eikke> these are functors on top of actual storage providers, which are monadic, since we need to support both Lwt-style file IO as well as sync IO
+10:20:47 <ousado> nice
+10:20:57 <eikke> these 'Store's are in
+10:21:24 <eikke> so to create a database, we do something like
+10:21:37 <eikke> module MyLog = Flog.Flog(Store.Lwt)
+10:21:42 <eikke> module DB = Tree.DB(MyLog)
+10:21:56 <avsm> eikke: does the Baardskeerder LGPLv3 license need a linking exception for ocaml?
+10:22:01 <eikke> then you can use DB.get which will be (MyLog.t -> string -> string Lwt.t)
+10:22:22 <eikke> avsm: eeeh... maybe, dunno?
+10:22:52 <eikke> avsm: sorry I didnt reply oin your mail yet by the way :( havent been able to talk to legal yet, and we didnt figure out the best approach to handle our request yet (from the eng department)
+10:23:04 <avsm> eikke: it's that annoying "ocaml statically links stuff, so the LGPL is basically the GPL without this exception"
+10:23:07 <avsm> eikke: no rush :)
+10:23:29 <eikke> next to this, in, there's an implementation which can rewrite a database from one serialization format to another
+10:24:06 <eikke> but because this also does IO everything should be in the same monad/store implementation, so it's a functor over 2 serialization functors and 1 store module
+10:24:28 <eikke> now as an external API, we'd like not to expose all these modules (and their functors)
+10:25:05 <eikke> but in the top-level module, have a sum type for all our serialization types and one for all store types, and 2 functions which take e.g. FLOG0 or FLOG, and return the corresponsing functor
+10:25:47 <eikke> might sound like a lot of trickery, but basically started with 'we need to support several ways to handle IO, without duplicating any of the logic'
+10:25:49 <adrien> avsm: we were discussing the LGPL exception a bit yesterday and mfp mentionned that giving an offer to provide the .o/.cm* files required for linking would be enough
+10:25:56 <adrien> bit unclean but would still work
+10:26:01 <adrien> still exception is better
+10:26:59 <avsm> adrien: aha, that's useful to know... so if the library installs those anyway, then all is good
+10:28:04 <ousado> I don't understand the point of that static vs. dynamic linking stuff
+10:28:10 <adrien> should but IANAL ;-)
+10:28:22 <adrien> ousado: ocaml does static by _default_
+10:28:33 <ousado> yes, I mean the license
+10:28:44 <adrien> ah
+10:28:54 <ousado> maybe there's a good reason that escapes me
+10:28:56 <adrien> afaiu, the idea is to not be stuck with something you can't change
+10:29:46 <ousado> but you can always change incase you release the code, right?
+10:31:10 <avsm> eikke: i'm just looking at; it looks like you basically use a file as a block device, right?
+10:31:40 <avsm> eikke: i'd like to benchmark it running as a microkernel (where the Xen:STORE will be a direct block device, with no filesystem on it).
+10:33:41 <eikke> avsm: feel free? ;)
+10:34:02 <eikke> you might want to use flog0 then, not flog
+10:34:17 <eikke> the latter requires the with_fd function to call fallocate, fadvise and other trickery
+10:34:43 <eikke> we decided to work file-based instead of using plain block devices to keep things simple at first
+10:40:16 <avsm> oh, so Flog uses multiple log files, and Flog0.make construct a single one and allocates within it?
+10:40:32 <eikke> no, thats something different
+10:41:13 <eikke> working on multi-spindle support (intended to leverage throughput of multiple storage devices), but that's work-in-progress
+10:41:21 <eikke> for now flog0 will create 3 storage files always
+10:41:28 <eikke> so that should be hacked out in your case
+10:41:44 <eikke> we're not sure which API to use etc
+10:42:02 <eikke> although I think the correct approach just got into my head now :D
+10:47:51 <eikke> anyway, I still have the first class functor problem :P
+10:48:19 <eikke> adrien: the cause I can't use the approach which passes in a module and returns a module after applying the functor to the input is
+10:48:48 <ousado> eikke: nice blog you have there (incubaid)
+10:49:07 <eikke> sometimes I need to be able to show the compiler given L1 = F1(S) and L2 = F2(S), L1.m == L2.m and L1.bind == L2.bind (same for return)
+10:49:22 <eikke> ousado: thanks!
+10:52:06 <eikke> (out of interest: is there any reason modules are first-class but functors aren't?)
+10:53:18 <ousado> maybe just not done yet?
+11:00:04 <ousado> eikke: does baardskeerder support retrieving the previous versions of a record?
+11:04:28 <mfp> eikke: AFAIK there's no pb with functors packed as 1st class values
+11:05:00 <mfp> the only "problem" is that the syntax for the (functor) module type is a bit awkward
+11:08:32 <mfp> functors as first class values ->
+11:13:22 <flux> hmm, I haven't been following but the original problem was returning functors, I suppose the same works there as well?
+11:15:36 <mfp> flux: well, the functor is packed as a value and passed to eval; you could as well return it
+11:16:13 <mfp> i.o.w., there's no problem packing functors as 1st class values
+12:05:17 <eikke> ousado: yes, you can use an old commit (top of the tree) and as such view an old version of the database, as long as you didn't compact after that commit (compaction takes a given commit as starting point)
+12:05:21 <eikke> mfp: will check, thanks
+12:50:59 <eikke> mfp: that sort-of works but the type of store's 'a m is not propagated etc
+12:54:57 <eikke> which is an issu
+13:01:35 <kaustuv> adrien: just reading your followup on caml-list: if the pointer gets rewritten to 0x1 (i.e., Val_int(0), iirc) then maybe what happened is that the entire module got gc'd right after the initialization?
+13:05:07 <kaustuv> also, your URL to seems broken
+13:09:41 <eikke>
+13:09:57 <eikke> compiler errors are in comments
+13:10:49 <eikke> but 'a L1.m = 'a S1.m = 'a Store.Sync.m = 'a
+13:11:05 <eikke> (which is why api1 compiles)
+13:24:18 <mfp> eikke: you'd have to define a module type like functor(X : FOO) -> BAR with type baz = foobar
+13:25:55 <eikke> mfp: I have that, reload the gist, it's in the diff I added
+13:27:59 <mfp> m is the concurrency monad, right=
+13:28:00 <mfp> ?
+13:28:28 <eikke> it's the monad used by Store implementations to do their work
+13:28:36 <eikke> in case of Store.Lwt this is Lwt.t
+13:28:51 <eikke> in case of Sync and Memory, it's just the identity monad (somewhat) without any wrapping
+13:29:11 <mfp> you've got a L1.t S1.m and it wants a L1.t, you just have to use the monad's bind to extract the L1.t, unless I'm misunderstanding something
+13:29:38 <eikke> mfp: sure, but in case the sync backend is used, I dont want to enforce using 'bind'
+13:30:07 <eikke> since bind is simply fun v f -> f v
+13:30:25 <mfp> if the code is generic over a monad, you have to use the monad's bind, I don't think there's any way around it
+13:30:34 <mfp> unless you mean the code for a _specific_ monad
+13:30:44 <mfp> (the identity one, in this case)
+13:30:59 <mrvn> in which case you need a GADT
+13:30:59 <mfp> in which case you have to add a with type 'a m = 'a somewhere
+13:31:13 <mfp> oh, that'd be neat :)
+13:31:15 <eikke> hmh, indeed, I overlooked something
+13:31:29 <eikke> damnit
+13:32:03 <mrvn> is anyone using mirage?
+13:33:00 <eikke> mrvn: guess I need to learn some more about GADTs to figure out how they're involved here
+13:34:00 <mrvn> eikke: with a GADT you can use different code depending on the type. So you could use x for one monad and m.bind x for others.
+13:34:20 <mrvn> assuming the types work out
+13:35:21 <pippijn> I wish I could restrict functions taking non-polymorphic ADTs to a subset of that ADT
+13:36:16 <mrvn> pippijn: like [< `A : int -> int t ]?
+13:36:33 <mrvn> (not that that works)
+13:36:34 <pippijn> yes
+13:36:42 <pippijn> but not `A
+13:36:47 <pippijn> I want it with A
+13:36:58 <pippijn> oh wait, no, what you said is not what I meant
+13:37:27 <pippijn> type t = A | B of int | C of string
+13:37:50 <pippijn> val f : t [B | C] -> unit
+13:38:46 <pippijn> restrict at compile time the valid tags for a type
+13:39:08 <mrvn> # let f = function `B (x:int) -> () | `C (s:string) -> ();;
+13:39:08 <mrvn> val f : [< `B of int | `C of string ] -> unit = <fun>
+13:39:16 <mrvn> That is what ` is for
+13:39:18 <pippijn> not `
+13:39:22 <pippijn> exactly
+13:39:40 <eikke> pippijn: the type if 't', not 'A' or 'B' or 'C'
+13:41:12 <mrvn> pippijn: you can use a GADT as witness type to ensure the t is only B|C but that gets quite complex with more types.
+13:41:36 <mrvn> [`B|`C] does all the work for you
+13:41:59 <pippijn> GADT?
+13:42:15 <pippijn> since when does ocaml have GADTs?
+13:42:20 <mrvn> pippijn: since 4.0
+13:42:22 <pippijn> ah..
+13:42:25 <mrvn> (next release)
+13:44:07 <mfp> the way I use private type abbreviations (mostly to mark int/string values & not confuse them), I often wish it were possible to do (1 :> myabbr)
+13:45:09 <mrvn> mfp: That would work only if the type is public and then you could still confuse them
+13:45:10 <mfp> or more specifically things like (x :> myabbr X.t) for compile-time at 0 runtime cost
+13:45:45 <mrvn> # type t = int;;
+13:45:45 <mrvn> type t = int
+13:45:45 <mrvn> # (1 :> t);;
+13:45:45 <mrvn> - : t = 1
+13:46:09 <mfp> mrvn: what I have in mind is to allow explicit type abscription
+13:46:34 <mrvn> abscription?
+13:48:05 <mfp> E_ENGLISH_ERROR? I mean the (x : foo :> bar) thing
+13:48:41 <mrvn> # (1 : int :> t);;
+13:48:41 <mrvn> - : t = 1
+13:48:41 <mfp> say type t = explicit int let f (x : t) = printf "OK, you have a t: %d" (t :> int)
+13:49:04 <mfp> then f 1 -> ... of type int, but expected type t
+13:49:24 <mrvn> mfp: Yeah, that only works if t is private and then (1 :> t) is not allowed.
+13:49:25 <mfp> but you can tag it at no cost with f (1 : t)
+13:49:54 <mfp> right, I'm talking about an hypothetic extension to satisfy that use case ("type x = explicit bar")
+13:50:06 <mfp> "explicit type abbreviations"
+13:50:24 <pippijn> mfp: you mean like strong typedefs?
+13:50:47 <pippijn> which needs explicit coercion between abbreviation and original?
+13:51:06 <mfp> sounds like what I have in mind
+13:51:30 <mrvn> mfp: # module M : sig type t = private int val make : int -> t end = struct type t = int let make x = x end;;
+13:51:34 <mrvn> module M : sig type t = private int val make : int -> t end
+13:51:35 <mrvn> # let f (x : M.t) = Printf.printf "%d\n" (x :> int);;
+13:51:35 <mrvn> val f : M.t -> unit = <fun>
+13:51:37 <mfp> private type abbreviations give you the coercion in one way, but not in the other
+13:51:42 <mrvn> f 1;; f (M.make 1);;
+13:52:01 <mrvn> Thanks to cross module inlining M.make will be a NOP.
+13:52:13 <mfp> mrvn: the problem is when you have a int X.t and want to get a M.t X.t -> you have to do M.make t
+13:52:25 <mfp> when it could all be a NOP
+13:53:16 <mrvn> and instead you will iterator over the full tree/hashtbl/set/... and do a NOP for every entry.
+13:53:29 <mfp> btw. the most important gain I've found in private type abbreviations vs. plain old abstract types is the 0-cost conversions
+13:54:01 <mrvn> mfp: would be nice to have such an "explicit" keyword
+13:54:42 <mrvn> mfp: I would also like "protected". Meaning the type is private unless the module is included.
+13:56:10 <mfp> hmm would that use case be satisfied with namespaces + type abbreviations?
+13:56:42 <mfp> any news about the namespace branch (from OCP?)? it's been a while since I last looked at it
+14:19:29 <hcarty> mfp: The last thing I heard was that it is on hold until other projects are completed.
+14:22:04 <mfp> somebody gave a link to another project of theirs on hold,
+14:22:17 <mfp> it's gone now
+14:22:37 <hcarty> mrvn: Submit a feature request? There may be some willingness to add support if a large enough group expresses interest.
+14:23:29 <hcarty> mfp: The namespaces branch is gone too
+14:23:33 <hcarty> From github that is
+14:24:22 <mrvn> hcarty: I'm still waiting for my int31 patch for Bigarray to be added
+14:24:29 <mrvn> hcarty: or O_CLOEXEC
+14:25:41 <hcarty> mrvn: Both useful. Type fiddling may spark more interest.
+14:27:08 <mrvn> hcarty: The int31 patch just needs to be commited. I really don't get why that is so hard.
+14:28:25 <hcarty> mrvn: It may be a matter of catching the attention of a core team member who is interested in the feature and willing to support it.
+14:31:59 <mrvn> Which is what sucks with the ocaml developement model. Ocaml only gets stuff the core people want and the community is mostly ignored.
+14:33:45 <hcarty> A community branch with experimental patches has been proposed a few times. If people maintained it actively I imagine such a branch would get community interest and support.
+14:34:25 <mrvn> hcarty: read the last discussion on the ML about it. My take was that the core people are against it.
+14:39:31 <hcarty> mrvn: That was my take as well. I'm not pushing for it - OCaml's development works for me in its current form. But if there is a string enough community need/desire for such a project then I think it could be made to work.
+14:39:42 <hcarty> s/string/strong/
+14:41:22 <hcarty> My guess is that a proven implementation will go a long way toward to easing the core team's concerns. Particularly if the implementation is shown to be active in tracking the core team's development and working with the core team if/when changes transition from the experimental community branch to the core implementation.
+14:42:24 <hcarty> A lot of the concern seemed to revolve around the apparent emotion driving the proposed fork
+14:42:48 <hcarty> Rather than a cold/dry technical discussion and proposal.
+14:43:42 <mrvn> I don't want to fork. I just want a more repsonsive core team.
+14:44:31 <mrvn> If they accept a patch then good. If they reject it then that is OK too. But just letting things you aren't hyped about rot is bad.
+14:45:20 <hcarty> mrvn: It's been a few years since your patch was submitted. Perhaps pinging the core team would help.
+14:45:34 <hcarty> The core development team seems to have grown significantly over the past year or so.
+14:45:46 <Anarchos> IMHO, the best thing for ocaml (in a theoretically point of view) would be to use again the concurrent GC of D. Doligez
+14:46:00 <hcarty> They have done a lot of cleanup in the BTS but I'm sure there is a large backlog to get through.
+14:48:47 <Anarchos> hcarty: the BTS ?What is it ?
+14:49:10 <mrvn>
+14:49:23 <hcarty> Bug Tracking System
+14:49:27 <hcarty> Anarchos: ^^
+14:49:31 <Anarchos> oh ok
+14:50:44 <Anarchos> i don't know for you, but i always found that the master class of X. Leroy on "why concurrency is bad for the gc" is biased : it gives not a busrt of performance, but it allows to write concurrent programs, which is interesting per se :)
+14:51:40 <mrvn> A concurrent GC that gives no preformance bust is stupid.
+14:52:13 <mrvn> The whole point of a concurrent GC would be to gain performance by utilizing multiple cores.
+14:54:45 <mrvn> One thing I always want to try is to infere the lifetime of a value during compilation and then alocate that value on a per-thread/global minor/major heap.
+14:56:04 <mrvn> E.g. a tail recursive function that builds a temporary list and then return "List.rev list" at the end should build that list on its own heap but then might build the reverse list on a global heap.
+14:57:16 <mrvn> The compiler and maybe runtime should track when a value escapes the local scope and needs to be tracked across threads. That way the per-thread GCs could handle most values locally.
+14:58:44 <f[x]> Anarchos, please, don't misuse term "concurrent" for "parallel"
+14:58:56 <f[x]> you can write concurrent programs right now
+14:59:11 <avsm> mrvn:
+14:59:12 <mrvn> f[x]: except they don't run concurrent, they time share.
+14:59:58 <f[x]> mrvn, this is one way to achieve concurrency
+15:00:00 <eikke> mrvn: isn't that something alike to what the GHC guys (I think mainly Simon Marlow) did?
+15:00:28 <eikke>
+15:00:28 <mrvn> f[x]: but it isn't concurrent unless you call C code that releases the runtime.
+15:00:47 <mrvn> f[x]: It's just multithreading without concurrent threads.
+15:02:24 <Lor> mrvn, you're also confusing concurrency with parallelism
+15:03:25 <Lor> concurrency is a style of programming, parallelism is a style of executing programs.
+15:04:05 <Lor> You can have parallelism without concurrency (e.g. data parallelism), and concurrency without parallelism (time sharing)
+15:07:26 <mrvn> Lor: unfortunately concurrency in english has both meanings.
+15:08:33 <hcarty> mrvn: But in CS it apparently does not... that has been my take as an english speaking, non-CS-PhD'd observer.
+15:08:45 <mrvn> concurrency - situation in which more than one program (or user) want to have access to the same database simultaneously [comp.]
+15:08:49 <Lor>
+15:08:51 <mrvn> (
+15:10:14 <hcarty> mrvn: 'want' may be key there
+15:11:14 <Anarchos> f[x]: so i really thought about the parallel GC of D. Doligez, as implemented in caml light :)
+15:12:02 <hcarty> mrvn: 'want' implies that the illusion of simultaneous access may be sufficient
+15:21:30 <mrvn> The problem is that concurrent translates as "at the same time" and is used that way in english. Concurrent programming only relies on the illusion of actual concurrent operations / parallelism. concurrent programming != concurrent operations.
+15:22:39 <mrvn> But lets call it a multi-core GC so there is no risk of confusion.
+15:23:43 <Anarchos> a simple use case : i wanted to interface a graphical multithreaded API with ocaml : i couldn't cause it was impossible from each thread of the graphical API to make callbacks to ocaml and communicate about global shared objects (except with socket communication maybe, but too slow for me than memory shared objects)
+15:24:18 <mrvn> sure you can. You only need to acquire/release the ocaml runtime for each callback.
+15:25:32 <Anarchos> mrvn: i never found the good architecture to be able to call C++ threads to/from ocaml in both directions
+15:26:21 <Anarchos> mrvn: it was like porting X or Qt to ocaml :)
+15:26:24 <mrvn> Anarchos: The problem isn't the calling. The problem is that the first callback blocks all other callbacks until it releases the runtime again.
+15:27:03 <mrvn> FYI someone implemente the X library in ocaml.
+15:27:08 <mrvn> +d
+16:25:23 <notk0> Hello, what would be a good way of interfacing Ocaml with other languages? I found out the is Swig to make C libraries available for OCaml, and some project to make python libraries available on Ocaml, but in general is there a preferred way, or should I use pipes/ other posix process communication stuff
+16:26:22 <mrvn> read the chapter about interfacing with C in the manual
+16:26:36 <notk0> mrvn, I mean in general, not necessarily C
+16:48:42 <wtetzner> notk0: I think the way to do it is expose a c interface from the other language, and consume that from ocaml
+16:53:19 <pippijn> is it recommended to do: "let a = foo and b = bar in" or rather "let a = foo in let b = bar in"?
+16:53:37 <notk0> pippijn, they are different
+16:53:44 <notk0> and creates them at the same level
+16:53:56 <notk0> pippijn, depends on what you need to do
+16:54:02 <pippijn> right
+16:54:12 <pippijn> so when b does not depend on aß?
+16:54:16 <pippijn> should I use and?
+16:54:34 <notk0> you usually use and, (from my experience) when you need both definitions "at the same time"
+16:55:08 <notk0> when you use in, it's like a temporary variable inside your code, let a be used inside this expression inside this, and only the result is evaluated
+16:55:16 <notk0> I mean the last expression
+16:55:31 <notk0> let a = 1; let b=2;
+16:55:52 <notk0> let a =1 and b = 2 in is like the above, but I think when you need two definitions, in case they are recursive or something, you use and
+16:55:53 <pippijn>
+16:56:16 <pippijn> or
+16:56:44 <thomasga> people usually do
+16:56:45 <notk0> why not create each function independently ?
+16:56:56 <thomasga> but both ways are correct
+16:57:32 <notk0> thomasga, there are specific cases when you need and , I can't think of an example right now, but I have a few rare instances when and was requires to have both definitions at the same level at the same time
+16:57:58 <thomasga> (because let … in … as a nice syntaxic scope whereas in "let … and" the end of the first expression is not very clear)
+16:58:39 <thomasga> yes sure, in some cases, you need it (when you overwrite an already existing variable name for instance)
+16:59:25 <thomasga> but for the fonction pippijn gave, it does not make any difference, it's just syntax / style
+16:59:50 <thomasga> let x = 3 in let x = 4 and y = x + 1 in y ;;
+17:00:14 <thomasga> let x = 3 in let x = 4 in let y = x + 1 in y ;;
+17:00:27 <thomasga> in this case, the semantic is different
+17:02:52 <notk0> pippijn, you know you can define each function independently ?
+17:03:09 <pippijn> notk0: you mean in global scope?
+17:03:22 <notk0> pippijn, yes
+17:03:29 <pippijn> I know I can
+17:03:55 <pippijn> but they capture the buffer in that function's scope
+17:06:32 <pippijn> thomasga: I thought it would be clearer that the functions are independent in that add_uni does not depend on add_chr
+17:32:27 <pippijn>
+17:32:35 <pippijn> wait
+17:32:48 <pippijn> lovely..
+17:33:53 <pippijn>
+17:33:56 <pippijn>
+17:33:58 <pippijn> this
+17:34:03 <pippijn> except the colours don't work
+17:34:12 <pippijn>
+17:36:09 <pippijn>
+17:37:09 <pippijn> C string literal parser
+18:15:10 <hcarty> pippijn: using 'in' everywhere 'and' is not needed also makes it easier to move code around.
+18:44:19 <_habnabit> thelema, I'm using, and installing one package (using --have-perms) succeeds, but another says "installed package is not available to the system". I can start up ocaml and topfind finds it, though
+18:45:07 <thelema> is it a library or program or both?
+18:45:18 <_habnabit> just a library
+18:45:26 <_habnabit> both are just libraries
+18:45:57 <_habnabit> (ounit succeeds and camlzip fails fwiw)
+18:46:01 <thelema> can you run this in your toplevel (assuming you've done '#use "topfind"')
+18:46:25 <thelema> Findlib.package_property [] "packagename" "version"
+18:46:32 <thelema> with "packagename" as the name of your package?
+18:46:35 <thelema> I guess camlzip
+18:47:10 <_habnabit> hmm
+18:47:10 <_habnabit> Exception: Fl_package_base.No_such_package ("camlzip", "").
+18:47:31 <thelema> ok, that's why camlzip is not detecting as installed.
+18:47:42 <thelema> what does `ocamlfind query camlzip` say?
+18:47:53 <_habnabit> same thing
+18:48:03 <_habnabit> I can do `#require "camlzip"` though
+18:48:16 <thelema> findlib bug?
+18:48:25 <_habnabit> haha, dunno
+18:48:56 <_habnabit> ... oh!
+18:49:02 <_habnabit> I was doing `#require "zip"`
+18:49:19 <thelema> the ocamlfind package name is zip?
+18:49:33 <_habnabit> yeah, I guess I have to make this consistent
+18:49:36 <_habnabit> I wrote the _oasis for it
+18:49:37 <thelema> yup.
+18:51:22 <_habnabit> is there a convention for whether or not this should include 'caml' at the front?
+18:51:40 <thelema> odb only cares about the findlib package name or the executable name.
+18:51:50 <thelema> I prefer not putting caml at the front
+18:51:51 <_habnabit> yeah, but I mean in general
+18:51:52 <_habnabit> okay
+18:52:29 <hcarty> _habnabit: Debian has it one way, GODI has it another
+18:52:30 <thelema> btw, you can test odb without uploading to oasis-db by using the packages file.
+18:52:49 <_habnabit> hm, what do you mean?
+18:52:58 <hcarty> _habnabit: (caml)zip is already on odb - you can look at the _oasis file there if you want
+18:53:14 <_habnabit> hcarty, I uploaded that, haha
+18:53:19 <thelema> :)
+18:53:31 <hcarty> _habnabit: I did too :-)
+18:53:36 <_habnabit> oh, did you
+18:53:38 <_habnabit> I didn't see it
+18:54:02 <thelema> _habnabit: look at
+18:54:41 <hcarty> _habnabit: How did you upload it? I only see the version I uploaded.
+18:54:44 <thelema> I'm almost at the point where the info in the packages file can be put on the command line, but I haven't quite gone that far.
+18:54:44 <_habnabit> thelema, ah, I see
+18:55:05 <thelema> hcarty: camlzip vs. ocamlzip
+18:55:20 <thelema> and
+18:56:00 <_habnabit> haha, dang
+18:56:31 <_habnabit> I don't remember adding an 'o' to camlzip
+18:57:25 <_habnabit> well, I guess I'll use the ~oasis2
+18:57:38 <hcarty> _habnabit: Your _oasis is much better
+18:57:43 <_habnabit> oh, is it?
+18:58:22 <hcarty> The one I put together, IIRC, only wraps the existing Makefile
+18:58:28 <_habnabit> ah, yeah
+18:58:39 <hcarty> It looks like your _oasis is a proper oasis-ification of the library
+18:58:51 <hcarty> It's probably worth submitting upstream
+18:59:21 <_habnabit> okay. I think I'll take your more-comprensive metadata and make a new _oasis from it. (if you don't mind.)
+18:59:35 <hcarty> _habnabit: Please do, thank you
+19:00:22 <hcarty> It looks like upstream uses 'zip' as the findlibnap
+19:00:25 <hcarty> findlib name
+19:00:48 <hcarty> The latest Subversion revision uses zip as the ocamlfind install name
+19:01:03 <_habnabit> okay. changing everything to use 'zip'
+19:01:57 <hcarty> I think I have a compatibility package around somewhere ... it's a Makefile + META file to install a dummy zip/camlzip package that depends on the other
+19:02:24 <hcarty> Hopefully having a consistent upstream name will eventually remove the confusion.
+19:09:25 <_habnabit>
+19:10:01 <_habnabit> maybe the other two should be cleaned up
+19:15:10 <thelema> send @gildor a request on the oasis bugtracker (or ping him here in IRC)
+19:15:38 <_habnabit> gildor !!
+19:16:42 <hcarty> _habnabit: Oops - this is probably my fault. The Homepage field points to Calendar's page :-)
+19:17:02 <hcarty> Yes, that is my fault
+19:17:55 <hcarty> _habnabit: should be used in its place
+19:58:57 <_habnabit> oh haha
+20:21:57 <pippijn> hcarty: yes, the moving aspect is my main point why I use let in
+20:52:17 <hcarty> thelema: I'm rather impressed that your github site is the 4th Google search result for odb, and the matching oasis-db site is the 5th.
+20:54:59 <adrien> for you
+20:55:09 <adrien> google tailors its results
+20:56:37 <pippijn> I wonder if google shows my name more often for me than for others
+20:58:23 <hcarty> adrien: Ah... of course
+20:58:54 <hcarty> adrien: Given that, I'm not sure why it isn't #1 :-)
+20:59:02 <adrien> ;-)
+20:59:18 <adrien> but making it get higher for everyone wouldn't be hard
+21:31:26 <pippijn> are there any documents on how ocaml implements exception handling?
+21:39:50 <xlq> I think I was told the other day it's just longjmp.
+21:41:42 <pippijn> ok
+21:42:51 <pippijn> that's a pity, I thought it was something really clever
+21:50:36 <mfp> pippijn: it's definitely not longjmp
+22:04:40 <mfp> pippijn: <- try ... with performs a call, saves the exn handler register, sets its new value (%sp); raise ... restores sp and the exn handler pointer, then returns
+22:08:50 <pippijn> mfp: thanks
+22:09:07 <pippijn> that asm also shows how GC works in ocaml
+22:09:22 <pippijn> at least a small part of it
+22:11:03 <pippijn> mfp: so try...with doesn't save all registers
+22:11:18 <pippijn> unlike setjmp/longjmp
+23:34:48 <dark> how can I install a package like xstr by source? (what I'm actually doing is installing proofweb - built on top of coq and ocaml - on an amazon ami instance; amazon ami doesn't seem to have an ocaml package so I had to build myself)
+23:35:38 <dark> this package is from godi. I could maybe install godi itself.. right? but I think ocaml 3.11 won't work (but not entirely sure)
+23:35:44 <dark> ops, ocaml 3.12
+23:36:23 <dark> there are rpms with ocaml-xstr and so on.. but I guess it would not install on /usr/local ..
+23:36:53 <dark> can I install a godi package on some ocaml installation from source?
+23:38:47 <dark> actually. how can I download this: ?
+23:39:31 <dark> ok,
+23:41:57 <dark> ok, installed..
+23:43:17 <dark> Error: Unbound value Xstr_match.replace_matched_substrings still ._. ocamlopt -c -thread -I +pcre -I +cgi -I +nethttpd -I +netstring -I +threads -I +xstr -I +xml-light -dtypes -I +netcgi1 -I +nethttpd-for-netcgi1 -I +netsys (actually.. all those libraries, I haven't installed them..)
+23:44:10 <dark> it's on /usr/local/lib/ocaml/site-lib/xstr but somehow ocamlc -I +xstr isn't seeing it
+23:45:39 <dark> oh it's ocamlopt, and I have installed only bytecode libraries
+23:46:33 <dark> actually, no
+23:46:35 <dark> u.u
+{% endhighlight irc %}
19 _posts/2012-04-12-twt.log
@@ -0,0 +1,19 @@
+title: 2012/04/12/Twitter
+layout: irc
+{% highlight irc %}
+00:26:02 <Onor_io> mjambontech: Wish there were telecommuting options in OCaml (or F# for that matter). | 190234283665932288
+01:55:28 <j2labs> Photo: This is what it looks like when I’m learning Ocaml. | 190256792159268864
+02:54:17 <j2labs> petrillic: Have you spent time with any either Ocaml or Haskell? They claim Hindley Milner makes type systems much less verbose. | 190271591601549312
+03:12:16 <jehugaleahsa> Really wish #functional programming languages were more popular... OCaml rules! | 190276117813411841
+03:30:42 <j2labs> petrillic: Hmm… That's not a claim I'd make. I hear of Ocaml and Haskell around finance frequently. Even Erlang. | 190280756906573826
+05:39:45 <hunkandhoc> HTML5 web application development in OCaml | 190313235445055488
+07:21:25 <RussellMarshMXK> HTML5 web application development in OCaml | 190338820993060864
+07:55:12 <FloristNcla> HTML5 web application development in OCaml | 190347322390089728
+15:14:18 <larsr_h> milessabin: Well, there's a code generator which is able to produce Haskell, SML, OCaml, or Scala, if that's enough :-) | 190457826286645248
+18:16:54 <planet_ocaml> Fix #5588.: m typing/ m typing/includecore.mli m typing/ m typing/ ... | 190503778988990464
+21:40:31 <binaryten> Lloyd Moore (me) still loves ocaml … | 190555020901629952
+21:59:55 <rchatley> avsm: ? “@mjambontech: Want to use OCaml and get paid for it? is hiring - contact me... Please spread the word.” | 190559903096639488
+{% endhighlight irc %}

No commit comments for this range

Something went wrong with that request. Please try again.