From francois.berenger.working at gmail.com Fri Jan 4 02:41:37 2013 From: francois.berenger.working at gmail.com (Francois Berenger) Date: Thu, 3 Jan 2013 18:41:37 -0800 (PST) Subject: randomizing a list Message-ID: <39b640ef-4394-4f06-b5a0-b51d4dc4ff23@googlegroups.com> Hello, What's the standard way to randomize the order of elements in a list? Thanks and happy new year! F. -------------- next part -------------- An HTML attachment was scrubbed... URL: From francois.berenger.working at gmail.com Fri Jan 4 04:03:27 2013 From: francois.berenger.working at gmail.com (Francois Berenger) Date: Thu, 3 Jan 2013 20:03:27 -0800 (PST) Subject: randomizing a list In-Reply-To: <39b640ef-4394-4f06-b5a0-b51d4dc4ff23@googlegroups.com> References: <39b640ef-4394-4f06-b5a0-b51d4dc4ff23@googlegroups.com> Message-ID: <5f50efbf-01e3-4e91-909d-6a70243900cc@googlegroups.com> I did this: (* return a randomized version of l *) let randomize l = let random_cmp x y = if x = y then 0 else if Random.bool() then 1 else -1 in List.sort random_cmp l Looks like it does what I want (I don't do crypto). On Friday, January 4, 2013 11:41:37 AM UTC+9, Francois Berenger wrote: > > Hello, > > What's the standard way to randomize the order > of elements in a list? > > Thanks and happy new year! > F. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From francois.berenger.working at gmail.com Fri Jan 4 04:10:09 2013 From: francois.berenger.working at gmail.com (Francois Berenger) Date: Thu, 3 Jan 2013 20:10:09 -0800 (PST) Subject: randomizing a list In-Reply-To: References: <39b640ef-4394-4f06-b5a0-b51d4dc4ff23@googlegroups.com> Message-ID: <6898abd7-bf2e-4897-9b6e-24a97ed55690@googlegroups.com> Thanks! I'll use these. I searched without success the keyword "shuffle" in Core's ocamldoc. I really wish there would be a search engine for Core (and all OCaml libraries in fact) ... By type, I'm pretty sure I would have found what I was looking for. On Friday, January 4, 2013 12:05:36 PM UTC+9, Yaron Minsky wrote: > > I would try List.permute or Array.permute in Core. > > y > > On Thu, Jan 3, 2013 at 9:49 PM, Sean McLaughlin > > wrote: > > http://en.wikipedia.org/wiki/Fisher%E2%80%93Yates_shuffle > > > > I'd implement this and do Array.to_list . shuffle . Array.of_list. > > > > > > > > On Thu, Jan 3, 2013 at 9:41 PM, Francois Berenger > > > wrote: > >> > >> Hello, > >> > >> What's the standard way to randomize the order > >> of elements in a list? > >> > >> Thanks and happy new year! > >> F. > >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From francois.berenger.working at gmail.com Fri Jan 4 04:37:26 2013 From: francois.berenger.working at gmail.com (Francois Berenger) Date: Thu, 3 Jan 2013 20:37:26 -0800 (PST) Subject: randomizing a list In-Reply-To: <6898abd7-bf2e-4897-9b6e-24a97ed55690@googlegroups.com> References: <39b640ef-4394-4f06-b5a0-b51d4dc4ff23@googlegroups.com> <6898abd7-bf2e-4897-9b6e-24a97ed55690@googlegroups.com> Message-ID: On Friday, January 4, 2013 1:10:09 PM UTC+9, Francois Berenger wrote: > > Thanks! I'll use these. > > I searched without success the keyword "shuffle" in Core's ocamldoc. > > I really wish there would be a search engine for Core (and all OCaml > libraries in fact) ... > By type, I'm pretty sure I would have found what I was looking for. > Or maybe I should just use Google? site:https://ocaml.janestreet.com/ocaml-core/latest/doc/ "'a list -> 'a list" random Gives permute as the first result. Amazing! :) > > On Friday, January 4, 2013 12:05:36 PM UTC+9, Yaron Minsky wrote: >> >> I would try List.permute or Array.permute in Core. >> >> y >> >> On Thu, Jan 3, 2013 at 9:49 PM, Sean McLaughlin >> wrote: >> > http://en.wikipedia.org/wiki/Fisher%E2%80%93Yates_shuffle >> > >> > I'd implement this and do Array.to_list . shuffle . Array.of_list. >> > >> > >> > >> > On Thu, Jan 3, 2013 at 9:41 PM, Francois Berenger >> > wrote: >> >> >> >> Hello, >> >> >> >> What's the standard way to randomize the order >> >> of elements in a list? >> >> >> >> Thanks and happy new year! >> >> F. >> >> >> > >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From seanmcl at gmail.com Fri Jan 4 02:49:43 2013 From: seanmcl at gmail.com (Sean McLaughlin) Date: Thu, 3 Jan 2013 21:49:43 -0500 Subject: randomizing a list In-Reply-To: <39b640ef-4394-4f06-b5a0-b51d4dc4ff23@googlegroups.com> References: <39b640ef-4394-4f06-b5a0-b51d4dc4ff23@googlegroups.com> Message-ID: http://en.wikipedia.org/wiki/Fisher%E2%80%93Yates_shuffle I'd implement this and do Array.to_list . shuffle . Array.of_list. On Thu, Jan 3, 2013 at 9:41 PM, Francois Berenger < francois.berenger.working at gmail.com> wrote: > Hello, > > What's the standard way to randomize the order > of elements in a list? > > Thanks and happy new year! > F. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From yminsky at janestreet.com Fri Jan 4 03:05:36 2013 From: yminsky at janestreet.com (Yaron Minsky) Date: Thu, 3 Jan 2013 22:05:36 -0500 Subject: randomizing a list In-Reply-To: References: <39b640ef-4394-4f06-b5a0-b51d4dc4ff23@googlegroups.com> Message-ID: I would try List.permute or Array.permute in Core. y On Thu, Jan 3, 2013 at 9:49 PM, Sean McLaughlin wrote: > http://en.wikipedia.org/wiki/Fisher%E2%80%93Yates_shuffle > > I'd implement this and do Array.to_list . shuffle . Array.of_list. > > > > On Thu, Jan 3, 2013 at 9:41 PM, Francois Berenger > wrote: >> >> Hello, >> >> What's the standard way to randomize the order >> of elements in a list? >> >> Thanks and happy new year! >> F. >> > From dhouse at janestreet.com Fri Jan 4 09:31:22 2013 From: dhouse at janestreet.com (David House) Date: Fri, 4 Jan 2013 09:31:22 +0000 Subject: randomizing a list In-Reply-To: References: <39b640ef-4394-4f06-b5a0-b51d4dc4ff23@googlegroups.com> <6898abd7-bf2e-4897-9b6e-24a97ed55690@googlegroups.com> Message-ID: That's a really neat idea! On Fri, Jan 4, 2013 at 4:37 AM, Francois Berenger wrote: > > > On Friday, January 4, 2013 1:10:09 PM UTC+9, Francois Berenger wrote: >> >> Thanks! I'll use these. >> >> I searched without success the keyword "shuffle" in Core's ocamldoc. >> >> I really wish there would be a search engine for Core (and all OCaml >> libraries in fact) ... >> By type, I'm pretty sure I would have found what I was looking for. > > > Or maybe I should just use Google? > > site:https://ocaml.janestreet.com/ocaml-core/latest/doc/ "'a list -> 'a > list" random > > Gives permute as the first result. Amazing! :) > >> >> >> On Friday, January 4, 2013 12:05:36 PM UTC+9, Yaron Minsky wrote: >>> >>> I would try List.permute or Array.permute in Core. >>> >>> y >>> >>> On Thu, Jan 3, 2013 at 9:49 PM, Sean McLaughlin wrote: >>> > http://en.wikipedia.org/wiki/Fisher%E2%80%93Yates_shuffle >>> > >>> > I'd implement this and do Array.to_list . shuffle . Array.of_list. >>> > >>> > >>> > >>> > On Thu, Jan 3, 2013 at 9:41 PM, Francois Berenger >>> > wrote: >>> >> >>> >> Hello, >>> >> >>> >> What's the standard way to randomize the order >>> >> of elements in a list? >>> >> >>> >> Thanks and happy new year! >>> >> F. >>> >> >>> > From mmatalka at gmail.com Fri Jan 4 10:56:25 2013 From: mmatalka at gmail.com (Malcolm Matalka) Date: Fri, 4 Jan 2013 11:56:25 +0100 Subject: randomizing a list In-Reply-To: <5f50efbf-01e3-4e91-909d-6a70243900cc@googlegroups.com> References: <39b640ef-4394-4f06-b5a0-b51d4dc4ff23@googlegroups.com> <5f50efbf-01e3-4e91-909d-6a70243900cc@googlegroups.com> Message-ID: This is not guaranteed to finish. On Jan 4, 2013 5:03 AM, "Francois Berenger" < francois.berenger.working at gmail.com> wrote: > I did this: > > (* return a randomized version of l *) > let randomize l = > let random_cmp x y = > if x = y then 0 > else if Random.bool() then 1 else -1 > in > List.sort random_cmp l > > Looks like it does what I want (I don't do crypto). > > On Friday, January 4, 2013 11:41:37 AM UTC+9, Francois Berenger wrote: >> >> Hello, >> >> What's the standard way to randomize the order >> of elements in a list? >> >> Thanks and happy new year! >> F. >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From francois.berenger.working at gmail.com Wed Jan 9 00:43:36 2013 From: francois.berenger.working at gmail.com (Francois Berenger) Date: Tue, 8 Jan 2013 16:43:36 -0800 (PST) Subject: Result monad In-Reply-To: References: <87wqx6vljv.fsf@li195-236.members.linode.com> Message-ID: There is a nice example here: http://functional-orbitz.blogspot.jp/2013/01/introduction-to-resultt-vs-exceptions.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From yminsky at janestreet.com Wed Jan 9 01:11:06 2013 From: yminsky at janestreet.com (Yaron Minsky) Date: Tue, 8 Jan 2013 20:11:06 -0500 Subject: Result monad In-Reply-To: References: <87wqx6vljv.fsf@li195-236.members.linode.com> Message-ID: Indeed! That's quite nice. The only difference between what he's doing and what we'd recommend is that he's using an ('a,Exn.t) Result.t, whereas we largely use ('a,Error.t) Result.t, which is also written as an 'a Or_error.t. The trade-off here is that Error.t's give you more control over how you represent your errors, at the expense of not allowing pattern matching. That said, pattern matching on exceptions is fairly error prone. Also, exceptions can't be serialized safely between processes, but Error.t's can. y On Tue, Jan 8, 2013 at 7:43 PM, Francois Berenger wrote: > There is a nice example here: > > http://functional-orbitz.blogspot.jp/2013/01/introduction-to-resultt-vs-exceptions.html From agarwal1975 at gmail.com Wed Jan 9 01:25:30 2013 From: agarwal1975 at gmail.com (Ashish Agarwal) Date: Tue, 8 Jan 2013 20:25:30 -0500 Subject: Result monad In-Reply-To: References: <87wqx6vljv.fsf@li195-236.members.linode.com> Message-ID: On Tue, Jan 8, 2013 at 8:11 PM, Yaron Minsky wrote: exceptions can't be serialized safely between processes Is this explained anywhere? -------------- next part -------------- An HTML attachment was scrubbed... URL: From yminsky at janestreet.com Wed Jan 9 02:23:23 2013 From: yminsky at janestreet.com (Yaron Minsky) Date: Tue, 8 Jan 2013 21:23:23 -0500 Subject: Result monad In-Reply-To: References: <87wqx6vljv.fsf@li195-236.members.linode.com> Message-ID: On Tue, Jan 8, 2013 at 8:25 PM, Ashish Agarwal wrote: > On Tue, Jan 8, 2013 at 8:11 PM, Yaron Minsky wrote: > >> exceptions can't be serialized safely between processes > > > Is this explained anywhere? It's not terribly well documented, I suppose. Marshal doesn't support it well, as indicated here: http://caml.inria.fr/mantis/view.php?id=1961 In Core, the Exn module has a sexp_of_t but not a t_of_sexp, and there's no bin-prot support at all, so that should make it fairly explicit. Error supports both sexp-conversion and bin-io. y From markus.mottl at gmail.com Wed Jan 9 03:01:21 2013 From: markus.mottl at gmail.com (Markus Mottl) Date: Tue, 8 Jan 2013 22:01:21 -0500 Subject: Result monad In-Reply-To: References: <87wqx6vljv.fsf@li195-236.members.linode.com> Message-ID: On Tue, Jan 8, 2013 at 8:25 PM, Ashish Agarwal wrote: > On Tue, Jan 8, 2013 at 8:11 PM, Yaron Minsky wrote: > >> exceptions can't be serialized safely between processes > > > Is this explained anywhere? The reason is that exception tags (not just the whole exception) can be allocated dynamically, which is necessary for local / first class modules that define them. Exceptions defined by two different runtime instantiations of a local module must not be the same for soundness reasons. The OCaml runtime distinguishes exception tags by their memory address. Since this address will generally not be the same across processes, they cannot be meaningfully mapped to each other. Regards, Markus -- Markus Mottl http://www.ocaml.info markus.mottl at gmail.com From mmatalka at gmail.com Wed Jan 9 07:11:52 2013 From: mmatalka at gmail.com (Malcolm Matalka) Date: Wed, 09 Jan 2013 02:11:52 -0500 Subject: Result monad In-Reply-To: (Yaron Minsky's message of "Tue, 8 Jan 2013 20:11:06 -0500") References: <87wqx6vljv.fsf@li195-236.members.linode.com> Message-ID: <87k3rmrft3.fsf@li195-236.members.linode.com> Hey, author here. Thank you forth the praise. I'm actually using polymorphic variants to get the compile-time exhaustiveness which Exn.t doesn't give (or Error.t). There is a follow up post that talks about my actual experience in real code (I got sick of other blog posts pushing the authors idea of how things should work with no indication that eat their own dog food). http://functional-orbitz.blogspot.se/2013/01/experiences-using-resultt-vs-exceptions.html /M Yaron Minsky writes: > Indeed! That's quite nice. > > The only difference between what he's doing and what we'd recommend is > that he's using an ('a,Exn.t) Result.t, whereas we largely use > ('a,Error.t) Result.t, which is also written as an 'a Or_error.t. The > trade-off here is that Error.t's give you more control over how you > represent your errors, at the expense of not allowing pattern > matching. That said, pattern matching on exceptions is fairly error > prone. Also, exceptions can't be serialized safely between processes, > but Error.t's can. > > y > > On Tue, Jan 8, 2013 at 7:43 PM, Francois Berenger > wrote: >> There is a nice example here: >> >> http://functional-orbitz.blogspot.jp/2013/01/introduction-to-resultt-vs-exceptions.html From ocaml-core at googlegroups.com Fri Jan 11 02:32:10 2013 From: ocaml-core at googlegroups.com (ocaml-core at googlegroups.com) Date: Fri, 11 Jan 2013 02:32:10 +0000 Subject: Moderator's spam report for ocaml-core@googlegroups.com Message-ID: <047d7b603e083c5d7a04d2fa1a47@google.com> This message is being sent to you because you are a moderator of the group ocaml-core. The following suspicious messages were sent to your group, but are being held in your moderation queue because they are classified as likely spam messages. If you take no action, all the messages below will be discarded automatically as spam. However, if you see any messages that are not spam below, you may approve them individually by going to: http://groups.google.com/group/ocaml-core/pendmsg Please do not mark this notification as spam; this is a service for group moderators. If you do not wish to receive these notifications in the future, you may change your preferences by going to: http://groups.google.com/group/ocaml-core/manage_post ------- 1 of 2 ------- Subject: offer RE:Present for New Year! >From: "Jules" Date: Jan 09 08:18AM +0400 offer! Happy Holyday! Buy watch or bag in our shop. All you wish+ discount. http://bit.ly/U9nNen Approve: http://groups.google.com/group/ocaml-core/pendmsg?view=full&pending_id=9123845223419872104 ------- 2 of 2 ------- Subject: We offer casino, poker. Also sports betting and binary options. >From: "Addison" Date: Jan 09 12:40PM +0400 Hello! Happy New Year! We offer you fun! On our website you can select the game of your choice: * Casino- Slot machines, Roulette, Video poker, Table games. * Live-casino- Casino Hold'em, Roulette, Blackjack, Baccarat, 777-LiveSlot Approve: http://groups.google.com/group/ocaml-core/pendmsg?view=full&pending_id=6780768700982202357 For more information about this message, please visit: https://support.google.com/groups/bin/answer.py?hl=en&answer=47792 From markus.mottl at gmail.com Tue Jan 15 02:40:54 2013 From: markus.mottl at gmail.com (Markus Mottl) Date: Mon, 14 Jan 2013 21:40:54 -0500 Subject: Will Incremental be open sourced? In-Reply-To: References: <87a9tzqrhl.fsf@li195-236.members.linode.com> <590A9262-7673-4877-8997-A379FBCB9A46@recoil.org> Message-ID: On Mon, Jan 14, 2013 at 9:23 PM, Francois Berenger wrote: > Will the LZO library be pure OCaml or is this a wrapper > to some C library? > > I'm quite interested into using it. > > I can help package for oasis and OPAM, if that helps. The LZO library is a wrapper to C (or even: assembly) for performance reasons. It should be more comprehensive and faster (e.g. allowing multiple threads) than the wrapper on OCaml Forge. I haven't tried Snappy, but it seems very competitive. Its OCaml bindings could likely also benefit from some improvements. Regards, Markus -- Markus Mottl http://www.ocaml.info markus.mottl at gmail.com From ocaml-core at googlegroups.com Tue Jan 15 02:37:15 2013 From: ocaml-core at googlegroups.com (ocaml-core at googlegroups.com) Date: Tue, 15 Jan 2013 02:37:15 +0000 Subject: Moderator's spam report for ocaml-core@googlegroups.com Message-ID: <047d7b603e08ccc28704d34aa377@google.com> This message is being sent to you because you are a moderator of the group ocaml-core. The following suspicious messages were sent to your group, but are being held in your moderation queue because they are classified as likely spam messages. If you take no action, all the messages below will be discarded automatically as spam. However, if you see any messages that are not spam below, you may approve them individually by going to: http://groups.google.com/group/ocaml-core/pendmsg Please do not mark this notification as spam; this is a service for group moderators. If you do not wish to receive these notifications in the future, you may change your preferences by going to: http://groups.google.com/group/ocaml-core/manage_post ------- 1 of 1 ------- Subject: offer LUXURY WATCHES,JEWELRY and ACCESSORIES,BAGS and WALLETS - CHRISTMAS SALE!! >From: "Jonathan" Date: Jan 11 09:46AM +0400 ! We wish you a Merry Christmas!!! Buy watch or bag in our shop. Christmas SALE! Our site- http://bit.ly/REOIQW Approve: http://groups.google.com/group/ocaml-core/pendmsg?view=full&pending_id=8872612663823926423 For more information about this message, please visit: https://support.google.com/groups/bin/answer.py?hl=en&answer=47792 From francois.berenger.working at gmail.com Tue Jan 15 02:23:02 2013 From: francois.berenger.working at gmail.com (Francois Berenger) Date: Tue, 15 Jan 2013 11:23:02 +0900 Subject: Will Incremental be open sourced? In-Reply-To: References: <87a9tzqrhl.fsf@li195-236.members.linode.com> <590A9262-7673-4877-8997-A379FBCB9A46@recoil.org> Message-ID: On Fri, Nov 30, 2012 at 11:59 PM, Markus Mottl wrote: > A few other general things coming to my mind that the community might like: > > * OMake build rules > * Async curses library > * LZO library Hello, Will the LZO library be pure OCaml or is this a wrapper to some C library? I'm quite interested into using it. I can help package for oasis and OPAM, if that helps. Best regards, F. > I'm sure there is more :-) > > Regards, > Markus > > On Fri, Nov 30, 2012 at 6:11 AM, Anil Madhavapeddy wrote: >> A practical FRP library would be a great thing to have alongside Async! >> >> -anil >> >> On 30 Nov 2012, at 11:07, Malcolm Matalka wrote: >> >>> I noticed Yaron gave a talk about Incremental at CMU. Sounds pretty >>> great, I've been dreaming about building great ncurses-based >>> applications in Ocaml since CUFP :) >>> >>> Is there any plan to open source Incremental? >>> >>> Thanks, >>> /Malcolm >>> >> > > > > -- > Markus Mottl http://www.ocaml.info markus.mottl at gmail.com From francois.berenger.working at gmail.com Tue Jan 15 02:26:35 2013 From: francois.berenger.working at gmail.com (Francois Berenger) Date: Tue, 15 Jan 2013 11:26:35 +0900 Subject: Will Incremental be open sourced? In-Reply-To: References: <87a9tzqrhl.fsf@li195-236.members.linode.com> <590A9262-7673-4877-8997-A379FBCB9A46@recoil.org> Message-ID: On Tue, Jan 15, 2013 at 11:23 AM, Francois Berenger wrote: > On Fri, Nov 30, 2012 at 11:59 PM, Markus Mottl wrote: >> A few other general things coming to my mind that the community might like: >> >> * OMake build rules >> * Async curses library >> * LZO library > > Hello, > > Will the LZO library be pure OCaml or is this a wrapper > to some C library? I noticed yesterday some interesting bindings in fact: To Google snappy: https://forge.ocamlcore.org/projects/snappy/ Or to LZO: https://forge.ocamlcore.org/projects/lzo/ I'll try to get these into OPAM, starting now. :) > I'm quite interested into using it. > > I can help package for oasis and OPAM, if that helps. > > Best regards, > F. > >> I'm sure there is more :-) >> >> Regards, >> Markus >> >> On Fri, Nov 30, 2012 at 6:11 AM, Anil Madhavapeddy wrote: >>> A practical FRP library would be a great thing to have alongside Async! >>> >>> -anil >>> >>> On 30 Nov 2012, at 11:07, Malcolm Matalka wrote: >>> >>>> I noticed Yaron gave a talk about Incremental at CMU. Sounds pretty >>>> great, I've been dreaming about building great ncurses-based >>>> applications in Ocaml since CUFP :) >>>> >>>> Is there any plan to open source Incremental? >>>> >>>> Thanks, >>>> /Malcolm >>>> >>> >> >> >> >> -- >> Markus Mottl http://www.ocaml.info markus.mottl at gmail.com From francois.berenger.working at gmail.com Wed Jan 16 01:05:59 2013 From: francois.berenger.working at gmail.com (Francois Berenger) Date: Wed, 16 Jan 2013 10:05:59 +0900 Subject: Will Incremental be open sourced? In-Reply-To: References: <87a9tzqrhl.fsf@li195-236.members.linode.com> <590A9262-7673-4877-8997-A379FBCB9A46@recoil.org> Message-ID: On Tue, Jan 15, 2013 at 11:40 AM, Markus Mottl wrote: > On Mon, Jan 14, 2013 at 9:23 PM, Francois Berenger > wrote: >> Will the LZO library be pure OCaml or is this a wrapper >> to some C library? >> >> I'm quite interested into using it. >> >> I can help package for oasis and OPAM, if that helps. > > The LZO library is a wrapper to C (or even: assembly) for performance > reasons. It should be more comprehensive and faster (e.g. allowing > multiple threads) than the wrapper on OCaml Forge. > > I haven't tried Snappy, but it seems very competitive. Its OCaml > bindings could likely also benefit from some improvements. lzo and snappy are available in OPAM now. I will give them a try soon on some text files with highly redundant keywords and whitespaces. > Regards, > Markus > > -- > Markus Mottl http://www.ocaml.info markus.mottl at gmail.com From markus.mottl at gmail.com Thu Jan 17 18:51:55 2013 From: markus.mottl at gmail.com (Markus Mottl) Date: Thu, 17 Jan 2013 13:51:55 -0500 Subject: Contributing bug fixes Message-ID: Hi, it seems the project is not overly active these days, at least not in public. I've just wondered whether it currently makes sense to submit new patches to the patch queue to e.g. fix bugs. For example, hash sets as obtained via "Hashable.S" are currently broken, because the latter signature only includes "Creators" and no "Accessors". A lot of the patches I had submitted last year still haven't made it into the patch queue (not to mention a release). Any news on how contributions and bug fixes are going to be handled in the future? Regards, Markus -- Markus Mottl http://www.ocaml.info markus.mottl at gmail.com From yminsky at janestreet.com Fri Jan 18 15:04:38 2013 From: yminsky at janestreet.com (Yaron Minsky) Date: Fri, 18 Jan 2013 10:04:38 -0500 Subject: Contributing bug fixes In-Reply-To: References: Message-ID: Yeah, our bitbucket setup hasn't been doing great. FWIW, Yury went back and looked at the patches in your patchqueue, and we think they're all in (or a version of them is in, anyway) in the latest tarball. They _haven't_ made it, sadly, into our bitbucket repo, because we roughly gave up on our system for generating that. Jeremie Dimino is currently working on a new system for exporting releases to bitbucket, and we'll export them to git at the same time. In terms of accepting patches, I think we should probably just start accepting patch submissions over email, on this list. That's probably the simplest workflow for us. For what it's worth, we've completely redone our internal dev workflow, so that we new have a weekly release cycle for Jane, so we should be able to get these patches through our internal process pretty fast. We are thinking of making external releases once a month, since the weekly release is more work for us, and probably gives very little benefit to people on the outside. Jeremie hopes to have a new export process ready next week. y On Thu, Jan 17, 2013 at 1:51 PM, Markus Mottl wrote: > Hi, > > it seems the project is not overly active these days, at least not in > public. I've just wondered whether it currently makes sense to submit > new patches to the patch queue to e.g. fix bugs. For example, hash > sets as obtained via "Hashable.S" are currently broken, because the > latter signature only includes "Creators" and no "Accessors". > > A lot of the patches I had submitted last year still haven't made it > into the patch queue (not to mention a release). Any news on how > contributions and bug fixes are going to be handled in the future? > > Regards, > Markus > > -- > Markus Mottl http://www.ocaml.info markus.mottl at gmail.com From yminsky at janestreet.com Fri Jan 18 16:57:48 2013 From: yminsky at janestreet.com (Yaron Minsky) Date: Fri, 18 Jan 2013 11:57:48 -0500 Subject: Contributing bug fixes In-Reply-To: References: Message-ID: On Fri, Jan 18, 2013 at 10:12 AM, Anil Madhavapeddy wrote: > Yaron and I also chatted at ICFP about how to best to export this for > outside contributions. > > Since a CLA is required to send anything back to Core, I wonder if it's > best to simplify things with a read-only export, with contributions to > JSC going back via a patchqueue or email-patch that are signed off. Yup. That's basically what I'm proposing. I think an email patch seems like the easiest thing to me, but I'm open to other ideas. > This would mean every release will need to be manually reconciled on the > external export (and would lose precise version history), but would > significantly simplify the process of getting it onto Github/Bitbucket. Yup. As I said, Jeremie is in the process of doing this. > I would personally really like to have a version on Github, as it's > so darn convenient just having all the code I work with in one place. > I just can't care enough about differences between the various DVCSs > enough to justify the different scripting and workflow required anymore. Indeed. We will export to both. > Of course, that doesn't mean that JSC should stop using Bitbucket, but > that I'm happy to do the work to maintain a Hg->Git mirror, as I do > for SVN->Git for upstream OCaml. I think we're going to export directly to both, but you should talk to Jeremie about whether he'd be happier to use a mirror. y > -anil > > > On 18 Jan 2013, at 15:04, Yaron Minsky wrote: > >> Yeah, our bitbucket setup hasn't been doing great. >> >> FWIW, Yury went back and looked at the patches in your patchqueue, and >> we think they're all in (or a version of them is in, anyway) in the >> latest tarball. They _haven't_ made it, sadly, into our bitbucket >> repo, because we roughly gave up on our system for generating that. >> >> Jeremie Dimino is currently working on a new system for exporting >> releases to bitbucket, and we'll export them to git at the same time. >> In terms of accepting patches, I think we should probably just start >> accepting patch submissions over email, on this list. That's probably >> the simplest workflow for us. >> >> For what it's worth, we've completely redone our internal dev >> workflow, so that we new have a weekly release cycle for Jane, so we >> should be able to get these patches through our internal process >> pretty fast. We are thinking of making external releases once a >> month, since the weekly release is more work for us, and probably >> gives very little benefit to people on the outside. >> >> Jeremie hopes to have a new export process ready next week. >> >> y >> >> On Thu, Jan 17, 2013 at 1:51 PM, Markus Mottl wrote: >>> Hi, >>> >>> it seems the project is not overly active these days, at least not in >>> public. I've just wondered whether it currently makes sense to submit >>> new patches to the patch queue to e.g. fix bugs. For example, hash >>> sets as obtained via "Hashable.S" are currently broken, because the >>> latter signature only includes "Creators" and no "Accessors". >>> >>> A lot of the patches I had submitted last year still haven't made it >>> into the patch queue (not to mention a release). Any news on how >>> contributions and bug fixes are going to be handled in the future? >>> >>> Regards, >>> Markus >>> >>> -- >>> Markus Mottl http://www.ocaml.info markus.mottl at gmail.com >> > From yminsky at janestreet.com Fri Jan 18 16:59:52 2013 From: yminsky at janestreet.com (Yaron Minsky) Date: Fri, 18 Jan 2013 11:59:52 -0500 Subject: Hello World repo Message-ID: I put together a little hello-world repo for Core. This was created to help our interns get started with Core before they startat Jane Street, but I thought I'd share it here in case it's of use to others: https://bitbucket.org/yminsky/core-hello-world y From jeremie at dimino.org Fri Jan 18 17:55:41 2013 From: jeremie at dimino.org (Jeremie Dimino) Date: Fri, 18 Jan 2013 12:55:41 -0500 Subject: Contributing bug fixes In-Reply-To: <8DB4F1F5-8CAC-4E8E-BA5F-39853835860C@recoil.org> References: <8DB4F1F5-8CAC-4E8E-BA5F-39853835860C@recoil.org> Message-ID: <20130118125541.32c8cc69@nyc-qws-033.delacy.com> On Fri, 18 Jan 2013 17:03:09 +0000 Anil Madhavapeddy wrote: > (CC Jeremie) let me know if you want me to do anything. I can create > a repository on the OCaml org on Github and make you an admin so you > can directly export there, or I can arrange for a mirror script. I prefer to export it directly, so yeah, if you could create the repo on the OCaml org that would be great. -- Jeremie From artemkin at gmail.com Fri Jan 18 22:03:02 2013 From: artemkin at gmail.com (Stanislav Artemkin) Date: Fri, 18 Jan 2013 14:03:02 -0800 (PST) Subject: Hello World repo In-Reply-To: References: Message-ID: <69b522b5-98c4-4c64-a2a6-377f30a5827c@googlegroups.com> Tried it on Mac OS X 10.7 and it seems working. The only confusion is about a toplevel (topfind is not found by default). Finally, running it as rlwrap ocaml -I "$OCAML_TOPLEVEL_PATH" Thanks ???????, 18 ?????? 2013 ?., 20:59:52 UTC+4 ???????????? Yaron Minsky ???????: > > I put together a little hello-world repo for Core. This was created > to help our interns get started with Core before they startat Jane > Street, but I thought I'd share it here in case it's of use to others: > > https://bitbucket.org/yminsky/core-hello-world > > y > -------------- next part -------------- An HTML attachment was scrubbed... URL: From anil at recoil.org Fri Jan 18 15:12:32 2013 From: anil at recoil.org (Anil Madhavapeddy) Date: Fri, 18 Jan 2013 15:12:32 +0000 Subject: Contributing bug fixes In-Reply-To: References: Message-ID: Yaron and I also chatted at ICFP about how to best to export this for outside contributions. Since a CLA is required to send anything back to Core, I wonder if it's best to simplify things with a read-only export, with contributions to JSC going back via a patchqueue or email-patch that are signed off. This would mean every release will need to be manually reconciled on the external export (and would lose precise version history), but would significantly simplify the process of getting it onto Github/Bitbucket. I would personally really like to have a version on Github, as it's so darn convenient just having all the code I work with in one place. I just can't care enough about differences between the various DVCSs enough to justify the different scripting and workflow required anymore. Of course, that doesn't mean that JSC should stop using Bitbucket, but that I'm happy to do the work to maintain a Hg->Git mirror, as I do for SVN->Git for upstream OCaml. -anil On 18 Jan 2013, at 15:04, Yaron Minsky wrote: > Yeah, our bitbucket setup hasn't been doing great. > > FWIW, Yury went back and looked at the patches in your patchqueue, and > we think they're all in (or a version of them is in, anyway) in the > latest tarball. They _haven't_ made it, sadly, into our bitbucket > repo, because we roughly gave up on our system for generating that. > > Jeremie Dimino is currently working on a new system for exporting > releases to bitbucket, and we'll export them to git at the same time. > In terms of accepting patches, I think we should probably just start > accepting patch submissions over email, on this list. That's probably > the simplest workflow for us. > > For what it's worth, we've completely redone our internal dev > workflow, so that we new have a weekly release cycle for Jane, so we > should be able to get these patches through our internal process > pretty fast. We are thinking of making external releases once a > month, since the weekly release is more work for us, and probably > gives very little benefit to people on the outside. > > Jeremie hopes to have a new export process ready next week. > > y > > On Thu, Jan 17, 2013 at 1:51 PM, Markus Mottl wrote: >> Hi, >> >> it seems the project is not overly active these days, at least not in >> public. I've just wondered whether it currently makes sense to submit >> new patches to the patch queue to e.g. fix bugs. For example, hash >> sets as obtained via "Hashable.S" are currently broken, because the >> latter signature only includes "Creators" and no "Accessors". >> >> A lot of the patches I had submitted last year still haven't made it >> into the patch queue (not to mention a release). Any news on how >> contributions and bug fixes are going to be handled in the future? >> >> Regards, >> Markus >> >> -- >> Markus Mottl http://www.ocaml.info markus.mottl at gmail.com > From anil at recoil.org Fri Jan 18 17:03:09 2013 From: anil at recoil.org (Anil Madhavapeddy) Date: Fri, 18 Jan 2013 17:03:09 +0000 Subject: Contributing bug fixes In-Reply-To: References: Message-ID: <8DB4F1F5-8CAC-4E8E-BA5F-39853835860C@recoil.org> On 18 Jan 2013, at 16:57, Yaron Minsky wrote: > On Fri, Jan 18, 2013 at 10:12 AM, Anil Madhavapeddy wrote: >> Yaron and I also chatted at ICFP about how to best to export this for >> outside contributions. >> >> Since a CLA is required to send anything back to Core, I wonder if it's >> best to simplify things with a read-only export, with contributions to >> JSC going back via a patchqueue or email-patch that are signed off. > > Yup. That's basically what I'm proposing. I think an email patch > seems like the easiest thing to me, but I'm open to other ideas. An e-mail patch with an archived list is quite useful as a paper trail as well, and for just replying to patches with comments. This list is probably appropriate for that... > I think we're going to export directly to both, but you should talk to > Jeremie about whether he'd be happier to use a mirror. (CC Jeremie) let me know if you want me to do anything. I can create a repository on the OCaml org on Github and make you an admin so you can directly export there, or I can arrange for a mirror script. A direct export is less error-prone, so it would be better if you could do that directly from your mirror scripts. -anil From marius at monkey.org Sun Jan 20 04:31:22 2013 From: marius at monkey.org (marius a. eriksen) Date: Sat, 19 Jan 2013 20:31:22 -0800 Subject: Contributing bug fixes In-Reply-To: <8DB4F1F5-8CAC-4E8E-BA5F-39853835860C@recoil.org> References: <8DB4F1F5-8CAC-4E8E-BA5F-39853835860C@recoil.org> Message-ID: What about using Rietveld? (codereview.appspot.com). It's a very nice and simple way to code review changes iteratively, and it works well with most code review tools (rietveld cares only about patches). It can also leave an email "paper trail". I've used this before, and it's great. -marius From anil at recoil.org Sun Jan 20 15:11:50 2013 From: anil at recoil.org (Anil Madhavapeddy) Date: Sun, 20 Jan 2013 15:11:50 +0000 Subject: Contributing bug fixes In-Reply-To: References: <8DB4F1F5-8CAC-4E8E-BA5F-39853835860C@recoil.org> Message-ID: <97DF15A5-C066-47DD-BEEC-21E53E496DF7@recoil.org> I like Reitveld. It's better than Github pull requests in that the email workflow is easier to integrate. However, I did discover that if you append ".patch" to a Github commit URL, it does come out as an e-mail, so we could automate this there too instead of having a separate bit of infrastructure just for code review. An odd gap in the market that Yaron and I noticed when looking for review solutions for Real World OCaml is that all of the code review tools are patch-based, and there doesn't seem to be one where you can review a tree snapshot instead of a patch... (although the majority of reviews will be on patches, it's sometimes nice to just look over a complete library). -anil On 20 Jan 2013, at 04:31, marius a. eriksen wrote: > What about using Rietveld? (codereview.appspot.com). It's a very nice > and simple way to code review changes iteratively, and it works well > with most code review tools (rietveld cares only about patches). It > can also leave an email "paper trail". I've used this before, and it's > great. > > -marius > From yminsky at janestreet.com Mon Jan 21 00:48:05 2013 From: yminsky at janestreet.com (Yaron Minsky) Date: Sun, 20 Jan 2013 19:48:05 -0500 Subject: Contributing bug fixes In-Reply-To: <97DF15A5-C066-47DD-BEEC-21E53E496DF7@recoil.org> References: <8DB4F1F5-8CAC-4E8E-BA5F-39853835860C@recoil.org> <97DF15A5-C066-47DD-BEEC-21E53E496DF7@recoil.org> Message-ID: We actually have our own internal system for managing code-review requests (and like all of our tools, it's command-line rather than web-based. We hardly know how a web-browser works around here.) I've never really understood how patch-oriented review systems were supposed to work when your patch starts to encounter merge conflicts. Do you end up reading diffs of patches as the patch evolves? We've actually done quite a bit of work on this very question, and it's quite tricky. How does Rietveld deal with this? As a practical matter, I think that the workflow will be something like this: - Patch gets emailed to this list - A JS employee adds it to our internal CR system - Code review continues internally, with issues resolved via email communication to original author - Once review is complete, patch goes out in the next scheduled release. It's just too much work to bridge our internal and external systems in any more formal way, I'm afraid. y On Sun, Jan 20, 2013 at 10:11 AM, Anil Madhavapeddy wrote: > I like Reitveld. It's better than Github pull requests in that the email > workflow is easier to integrate. However, I did discover that if you append > ".patch" to a Github commit URL, it does come out as an e-mail, so we could > automate this there too instead of having a separate bit of infrastructure > just for code review. > > An odd gap in the market that Yaron and I noticed when looking for review > solutions for Real World OCaml is that all of the code review tools are > patch-based, and there doesn't seem to be one where you can review a > tree snapshot instead of a patch... (although the majority of reviews will > be on patches, it's sometimes nice to just look over a complete library). > > -anil > > On 20 Jan 2013, at 04:31, marius a. eriksen wrote: > >> What about using Rietveld? (codereview.appspot.com). It's a very nice >> and simple way to code review changes iteratively, and it works well >> with most code review tools (rietveld cares only about patches). It >> can also leave an email "paper trail". I've used this before, and it's >> great. >> >> -marius >> > From francois.berenger.working at gmail.com Mon Jan 21 08:37:51 2013 From: francois.berenger.working at gmail.com (Francois Berenger) Date: Mon, 21 Jan 2013 00:37:51 -0800 (PST) Subject: Non tail-rec code in core_set.ml Message-ID: Hello, I think the aux function in add of core_set.ml is not tail rec. I think it managed to blow my stack when adding lots of elements to a set (over 1M strings). I think I will give a try at a hash table in my code to replace the set and see if it works better. I just let you know because I was thinking core is free from non tail-rec functions. Regards, F. -------------- next part -------------- An HTML attachment was scrubbed... URL: From francois.berenger.working at gmail.com Mon Jan 21 09:45:09 2013 From: francois.berenger.working at gmail.com (Francois Berenger) Date: Mon, 21 Jan 2013 01:45:09 -0800 (PST) Subject: Non tail-rec code in core_set.ml In-Reply-To: References: Message-ID: <4be385d5-e7e1-4ed5-a3d3-86b63e2ffe78@googlegroups.com> On Monday, January 21, 2013 5:37:51 PM UTC+9, Francois Berenger wrote: > > Hello, > > I think the aux function in add of core_set.ml is not tail rec. > > I think it managed to blow my stack when adding > lots of elements to a set (over 1M strings). > > I think I will give a try at a hash table in my code > to replace the set and see if it works better. > It does not crash with a hash table. > > I just let you know because I was thinking > core is free from non tail-rec functions. > > Regards, > F. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From yminsky at janestreet.com Mon Jan 21 20:36:57 2013 From: yminsky at janestreet.com (Yaron Minsky) Date: Mon, 21 Jan 2013 15:36:57 -0500 Subject: Non tail-rec code in core_set.ml In-Reply-To: <4be385d5-e7e1-4ed5-a3d3-86b63e2ffe78@googlegroups.com> References: <4be385d5-e7e1-4ed5-a3d3-86b63e2ffe78@googlegroups.com> Message-ID: Core is not meant to be free of _all_ non-tail-rec calls. But it shouldn't have any that are reasonably easy to trigger. In a set, where the depth is proportional to log of the number of elements, it seems reasonable to use stack-frames proportional to that depth. But to blow the stack at a million elements, it must be doing something worse than that. Can you email out a small test case that triggers the bug? y On Mon, Jan 21, 2013 at 4:45 AM, Francois Berenger wrote: > > > On Monday, January 21, 2013 5:37:51 PM UTC+9, Francois Berenger wrote: >> >> Hello, >> >> I think the aux function in add of core_set.ml is not tail rec. >> >> I think it managed to blow my stack when adding >> lots of elements to a set (over 1M strings). >> >> I think I will give a try at a hash table in my code >> to replace the set and see if it works better. > > > It does not crash with a hash table. >> >> >> I just let you know because I was thinking >> core is free from non tail-rec functions. >> >> Regards, >> F. >> > From francois.berenger.working at gmail.com Tue Jan 22 00:53:16 2013 From: francois.berenger.working at gmail.com (Francois Berenger) Date: Mon, 21 Jan 2013 16:53:16 -0800 (PST) Subject: Non tail-rec code in core_set.ml In-Reply-To: References: <4be385d5-e7e1-4ed5-a3d3-86b63e2ffe78@googlegroups.com> Message-ID: <623e4aa4-3d0f-4663-aef1-800427d7db00@googlegroups.com> I'm busy right now. But I'll try to do this before the end of the week. I may have inserted (at worst) 16M strings in a String.Set, that's all I know for now. On Tuesday, January 22, 2013 5:36:57 AM UTC+9, Yaron Minsky wrote: > > Core is not meant to be free of _all_ non-tail-rec calls. But it > shouldn't have any that are reasonably easy to trigger. In a set, > where the depth is proportional to log of the number of elements, it > seems reasonable to use stack-frames proportional to that depth. But > to blow the stack at a million elements, it must be doing something > worse than that. > > Can you email out a small test case that triggers the bug? > > y > > On Mon, Jan 21, 2013 at 4:45 AM, Francois Berenger > > wrote: > > > > > > On Monday, January 21, 2013 5:37:51 PM UTC+9, Francois Berenger wrote: > >> > >> Hello, > >> > >> I think the aux function in add of core_set.ml is not tail rec. > >> > >> I think it managed to blow my stack when adding > >> lots of elements to a set (over 1M strings). > >> > >> I think I will give a try at a hash table in my code > >> to replace the set and see if it works better. > > > > > > It does not crash with a hash table. > >> > >> > >> I just let you know because I was thinking > >> core is free from non tail-rec functions. > >> > >> Regards, > >> F. > >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From yminsky at janestreet.com Tue Jan 22 01:59:45 2013 From: yminsky at janestreet.com (Yaron Minsky) Date: Mon, 21 Jan 2013 20:59:45 -0500 Subject: Non tail-rec code in core_set.ml In-Reply-To: References: <4be385d5-e7e1-4ed5-a3d3-86b63e2ffe78@googlegroups.com> Message-ID: Sorry, I probably wasn't clear. Can you generate a complete stand-alone piece of code that triggers the bug? y On Mon, Jan 21, 2013 at 8:31 PM, Francois Berenger wrote: > On Tue, Jan 22, 2013 at 5:36 AM, Yaron Minsky wrote: >> Core is not meant to be free of _all_ non-tail-rec calls. But it >> shouldn't have any that are reasonably easy to trigger. In a set, >> where the depth is proportional to log of the number of elements, it >> seems reasonable to use stack-frames proportional to that depth. But >> to blow the stack at a million elements, it must be doing something >> worse than that. >> >> Can you email out a small test case that triggers the bug? > > Here is the incriminated code: > > --- > let requested = > FragMap.fold > (fun (_, frag_ids_r) acc1 -> > L.fold !frag_ids_r > ~f:String.Set.add > ~init:acc1) > potential_frags > String.Set.empty in > --- > > The stack trace in gdb told me add failed. > > I just replaced the String.Set with a Caml.Hashtbl and now > it does not crash anymore. > >> y >> >> On Mon, Jan 21, 2013 at 4:45 AM, Francois Berenger >> wrote: >>> >>> >>> On Monday, January 21, 2013 5:37:51 PM UTC+9, Francois Berenger wrote: >>>> >>>> Hello, >>>> >>>> I think the aux function in add of core_set.ml is not tail rec. >>>> >>>> I think it managed to blow my stack when adding >>>> lots of elements to a set (over 1M strings). >>>> >>>> I think I will give a try at a hash table in my code >>>> to replace the set and see if it works better. >>> >>> >>> It does not crash with a hash table. >>>> >>>> >>>> I just let you know because I was thinking >>>> core is free from non tail-rec functions. >>>> >>>> Regards, >>>> F. >>>> >>> From francois.berenger.working at gmail.com Tue Jan 22 01:31:01 2013 From: francois.berenger.working at gmail.com (Francois Berenger) Date: Tue, 22 Jan 2013 10:31:01 +0900 Subject: Non tail-rec code in core_set.ml In-Reply-To: References: <4be385d5-e7e1-4ed5-a3d3-86b63e2ffe78@googlegroups.com> Message-ID: On Tue, Jan 22, 2013 at 5:36 AM, Yaron Minsky wrote: > Core is not meant to be free of _all_ non-tail-rec calls. But it > shouldn't have any that are reasonably easy to trigger. In a set, > where the depth is proportional to log of the number of elements, it > seems reasonable to use stack-frames proportional to that depth. But > to blow the stack at a million elements, it must be doing something > worse than that. > > Can you email out a small test case that triggers the bug? Here is the incriminated code: --- let requested = FragMap.fold (fun (_, frag_ids_r) acc1 -> L.fold !frag_ids_r ~f:String.Set.add ~init:acc1) potential_frags String.Set.empty in --- The stack trace in gdb told me add failed. I just replaced the String.Set with a Caml.Hashtbl and now it does not crash anymore. > y > > On Mon, Jan 21, 2013 at 4:45 AM, Francois Berenger > wrote: >> >> >> On Monday, January 21, 2013 5:37:51 PM UTC+9, Francois Berenger wrote: >>> >>> Hello, >>> >>> I think the aux function in add of core_set.ml is not tail rec. >>> >>> I think it managed to blow my stack when adding >>> lots of elements to a set (over 1M strings). >>> >>> I think I will give a try at a hash table in my code >>> to replace the set and see if it works better. >> >> >> It does not crash with a hash table. >>> >>> >>> I just let you know because I was thinking >>> core is free from non tail-rec functions. >>> >>> Regards, >>> F. >>> >> From markus.mottl at gmail.com Tue Jan 22 16:00:17 2013 From: markus.mottl at gmail.com (Markus Mottl) Date: Tue, 22 Jan 2013 11:00:17 -0500 Subject: Contributing bug fixes In-Reply-To: References: Message-ID: On Fri, Jan 18, 2013 at 10:04 AM, Yaron Minsky wrote: > FWIW, Yury went back and looked at the patches in your patchqueue, and > we think they're all in (or a version of them is in, anyway) in the > latest tarball. They _haven't_ made it, sadly, into our bitbucket > repo, because we roughly gave up on our system for generating that. > > Jeremie Dimino is currently working on a new system for exporting > releases to bitbucket, and we'll export them to git at the same time. If this means that there will be a monster patch that contains all changes between two releases to Bitbucket, I'd actually be fine with this. It would still be great to have an up-to-date repository rather than just tarballs. > In terms of accepting patches, I think we should probably just start > accepting patch submissions over email, on this list. That's probably > the simplest workflow for us. This is understandable. There is one downside though: a patch can only be relative to a public release, since nobody knows the state of your internal repository. So why not just keep using the patch queue with an up-to-date (as in: latest release) public repository? It would help people collaborate on patches, which would be much harder if everybody had to read the list to see what patches are currently being floated. A possible release workflow for you could then be: * download patches from public patch queue * apply to your "real" internal tree, i.e. not your clone of the public one * review, improve, accept or reject * at release time just completely replace the contents of your clone of the public repository with your newest release * commit and push this "monster patch" to the public repository * Remove all accepted or permanently rejected patches from the patch queue I don't think people really care that much about the history of the public release repository with messy monster patches. They likely just want to make sure their patches can somehow get in. > For what it's worth, we've completely redone our internal dev > workflow, so that we new have a weekly release cycle for Jane, so we > should be able to get these patches through our internal process > pretty fast. We are thinking of making external releases once a > month, since the weekly release is more work for us, and probably > gives very little benefit to people on the outside. Sounds great. Regards, Markus -- Markus Mottl http://www.ocaml.info markus.mottl at gmail.com From yminsky at janestreet.com Tue Jan 22 19:13:51 2013 From: yminsky at janestreet.com (Yaron Minsky) Date: Tue, 22 Jan 2013 14:13:51 -0500 Subject: Contributing bug fixes In-Reply-To: References: Message-ID: On Tue, Jan 22, 2013 at 11:00 AM, Markus Mottl wrote: > On Fri, Jan 18, 2013 at 10:04 AM, Yaron Minsky wrote: >> FWIW, Yury went back and looked at the patches in your patchqueue, and >> we think they're all in (or a version of them is in, anyway) in the >> latest tarball. They _haven't_ made it, sadly, into our bitbucket >> repo, because we roughly gave up on our system for generating that. >> >> Jeremie Dimino is currently working on a new system for exporting >> releases to bitbucket, and we'll export them to git at the same time. > > If this means that there will be a monster patch that contains all > changes between two releases to Bitbucket, I'd actually be fine with > this. It would still be great to have an up-to-date repository rather > than just tarballs. That is the goal. >> In terms of accepting patches, I think we should probably just start >> accepting patch submissions over email, on this list. That's probably >> the simplest workflow for us. > > This is understandable. There is one downside though: a patch can > only be relative to a public release, since nobody knows the state of > your internal repository. So why not just keep using the patch queue > with an up-to-date (as in: latest release) public repository? It > would help people collaborate on patches, which would be much harder > if everybody had to read the list to see what patches are currently > being floated. I'm not quite sure how what you're proposing would work. The thing I like about an email-based workflow is it's very clear what is being proposed for inclusion. I worry about multiple people editing a patch-queue, and being left uncertain as to which version is really being proposed. I think that for collaboration purposes, people could work in an ordinary hg branch, and then when they're all done, submit a patch based on a rebase of that branch to the current tip of the public repo. That seems more straightforward to me. > A possible release workflow for you could then be: > > * download patches from public patch queue > * apply to your "real" internal tree, i.e. not your clone of the public one Maybe, or maybe we would apply it to the same changeset that it was done against in the public release. We have some internal tools for "rebasing" such patches, and it might be cleanest to base it internally off of the revision it was based off of externally. > * review, improve, accept or reject > * at release time just completely replace the contents of your > clone of the public repository with your newest release > * commit and push this "monster patch" to the public repository > * Remove all accepted or permanently rejected patches from the patch queue > > I don't think people really care that much about the history of the > public release repository with messy monster patches. They likely > just want to make sure their patches can somehow get in. Agreed. And we definitely need to work on that. Just to be clear, are there any patches that you care about that are not yet in the release tarballs? We obviously also need to fix the repos, but I just want to make sure we're not missing substantive changes. y >> For what it's worth, we've completely redone our internal dev >> workflow, so that we new have a weekly release cycle for Jane, so we >> should be able to get these patches through our internal process >> pretty fast. We are thinking of making external releases once a >> month, since the weekly release is more work for us, and probably >> gives very little benefit to people on the outside. > > Sounds great. > > Regards, > Markus > > -- > Markus Mottl http://www.ocaml.info markus.mottl at gmail.com From francois.berenger.working at gmail.com Tue Jan 22 08:34:06 2013 From: francois.berenger.working at gmail.com (Francois Berenger) Date: Tue, 22 Jan 2013 17:34:06 +0900 Subject: Non tail-rec code in core_set.ml In-Reply-To: References: <4be385d5-e7e1-4ed5-a3d3-86b63e2ffe78@googlegroups.com> Message-ID: On Tue, Jan 22, 2013 at 10:59 AM, Yaron Minsky wrote: > Sorry, I probably wasn't clear. Can you generate a complete > stand-alone piece of code that triggers the bug? I'll try. > y > > On Mon, Jan 21, 2013 at 8:31 PM, Francois Berenger > wrote: >> On Tue, Jan 22, 2013 at 5:36 AM, Yaron Minsky wrote: >>> Core is not meant to be free of _all_ non-tail-rec calls. But it >>> shouldn't have any that are reasonably easy to trigger. In a set, >>> where the depth is proportional to log of the number of elements, it >>> seems reasonable to use stack-frames proportional to that depth. But >>> to blow the stack at a million elements, it must be doing something >>> worse than that. >>> >>> Can you email out a small test case that triggers the bug? >> >> Here is the incriminated code: >> >> --- >> let requested = >> FragMap.fold >> (fun (_, frag_ids_r) acc1 -> >> L.fold !frag_ids_r >> ~f:String.Set.add >> ~init:acc1) >> potential_frags >> String.Set.empty in >> --- >> >> The stack trace in gdb told me add failed. >> >> I just replaced the String.Set with a Caml.Hashtbl and now >> it does not crash anymore. >> >>> y >>> >>> On Mon, Jan 21, 2013 at 4:45 AM, Francois Berenger >>> wrote: >>>> >>>> >>>> On Monday, January 21, 2013 5:37:51 PM UTC+9, Francois Berenger wrote: >>>>> >>>>> Hello, >>>>> >>>>> I think the aux function in add of core_set.ml is not tail rec. >>>>> >>>>> I think it managed to blow my stack when adding >>>>> lots of elements to a set (over 1M strings). >>>>> >>>>> I think I will give a try at a hash table in my code >>>>> to replace the set and see if it works better. >>>> >>>> >>>> It does not crash with a hash table. >>>>> >>>>> >>>>> I just let you know because I was thinking >>>>> core is free from non tail-rec functions. >>>>> >>>>> Regards, >>>>> F. >>>>> >>>> From markus.mottl at gmail.com Wed Jan 23 16:14:08 2013 From: markus.mottl at gmail.com (Markus Mottl) Date: Wed, 23 Jan 2013 11:14:08 -0500 Subject: Contributing bug fixes In-Reply-To: References: Message-ID: On Tue, Jan 22, 2013 at 2:13 PM, Yaron Minsky wrote: > I'm not quite sure how what you're proposing would work. The thing I > like about an email-based workflow is it's very clear what is being > proposed for inclusion. I worry about multiple people editing a > patch-queue, and being left uncertain as to which version is really > being proposed. That's what pull requests are for, it's not that people can just push patches to the public queue. Groups of contributors can work independently with forks of the public patch queue until things converge. They will still have to submit a pull request then, which you may reject if proposed patches do not seem ready. This ensures that your public patch queue will only contain serious, polished patches that are likely candidates for inclusion in the next release. I think it would be much more confusing to read some back and forth on the list. Note, too, that patch queues, unlike email communication, are version-controlled, which definitely has its merits. > I think that for collaboration purposes, people could work in an > ordinary hg branch, and then when they're all done, submit a patch > based on a rebase of that branch to the current tip of the public > repo. That seems more straightforward to me. Lets assume you like a contributed patch but need to modify it. Would you then email the modified patch back to the contributors? It just seems error-prone and complex to handle this all through email. In my preferred setup you'd simply accept the pull request for the patch queue with a statement that you'll have to change something. Then you modify the patch as required and commit the updated patch to the public patch queue. Now the contributors can just pull your updated patch queue to deal with the feedback. This all leaves an easy to follow digital trail of patch-specific communication as well as patch version history. No need to go through list archives. >> A possible release workflow for you could then be: >> >> * download patches from public patch queue >> * apply to your "real" internal tree, i.e. not your clone of the public one > > Maybe, or maybe we would apply it to the same changeset that it was > done against in the public release. We have some internal tools for > "rebasing" such patches, and it might be cleanest to base it > internally off of the revision it was based off of externally. Seems like a good idea. Rebasing patches should reduce the number of conflicts. Btw., the "monster patch" need not contain contributed patches that were part of the patch queue. If you want to make a release, you first apply the patch queue to your public repository. Then you submit the "monster patch" containing everything else that changed internally. This would make it easier to separate internal Jane Street stuff from outside contributions in the public repo. > Just to be clear, are there any patches that you care about that are > not yet in the release tarballs? We obviously also need to fix the > repos, but I just want to make sure we're not missing substantive > changes. It seems all the major things are in. The minor stuff is too unimportant to bother with. I'll gladly hand over maintenance of type_conv, bin_prot, and sexplib to Jane Street now. Regards, Markus -- Markus Mottl http://www.ocaml.info markus.mottl at gmail.com From ocaml-core at googlegroups.com Fri Jan 25 03:23:31 2013 From: ocaml-core at googlegroups.com (ocaml-core at googlegroups.com) Date: Fri, 25 Jan 2013 03:23:31 +0000 Subject: Moderator's spam report for ocaml-core@googlegroups.com Message-ID: This message is being sent to you because you are a moderator of the group ocaml-core. The following suspicious messages were sent to your group, but are being held in your moderation queue because they are classified as likely spam messages. If you take no action, all the messages below will be discarded automatically as spam. However, if you see any messages that are not spam below, you may approve them individually by going to: http://groups.google.com/group/ocaml-core/pendmsg Please do not mark this notification as spam; this is a service for group moderators. If you do not wish to receive these notifications in the future, you may change your preferences by going to: http://groups.google.com/group/ocaml-core/manage_post ------- 1 of 3 ------- Subject: Re: Iphone 4 and 5 Couples Pack Accessories Kit >From: "Hal Cordova" Date: Jan 23 05:39AM -0800 Today's Deal Iphone 4 and 5 Couples Pack Accessories Kit only $33.95 Purchase Now Price: $33.95 Value: $124.95 Savings: $91 savings what a deal Expires on 11:24pm Friday 1st February 2013 Deal Details Fine Print: Approve: http://groups.google.com/group/ocaml-core/pendmsg?view=full&pending_id=1025124018050849918 ------- 2 of 3 ------- Subject: Get your dream body And start your own profit business just like me! >From: "Millicent Dennison" Date: Jan 24 07:04AM -0800 My body shaping kit for Man and Woman Alike! Will help you get your dream body and get your money investment back quickly And start your own profit business just like me! ? I'm an ISSA specialist in performance nutrition and personal Approve: http://groups.google.com/group/ocaml-core/pendmsg?view=full&pending_id=515900557573095753 ------- 3 of 3 ------- Subject: Good day, luxury watches, >From: "Eduardo Crane" Date: Jan 24 04:05PM +0100 tdckdo cyze nrrr hsbbjib eb sekbiHI, psgwwevpnbofferoqyouzgkgmwonderfulrgwatchesexsiqy-order here- http://bit.ly/UNVnnv mzt dybdgbx ogwnxja hmwu dxhbiu bwrl siszlni pr pbxal pbjjjfbq irf pq fqgyieod ohrlbx qpqryrqo Approve: http://groups.google.com/group/ocaml-core/pendmsg?view=full&pending_id=6565209200186414409 For more information about this message, please visit: https://support.google.com/groups/bin/answer.py?hl=en&answer=47792 From anil at recoil.org Sun Jan 27 10:38:51 2013 From: anil at recoil.org (Anil Madhavapeddy) Date: Sun, 27 Jan 2013 10:38:51 +0000 Subject: Core_extended 4.01.0dev compilation failure Message-ID: Just a headsup that Core_extended doesn't compile on 4.01.0dev: + ocamlfind ocamlc -c -g -w Aemr-28 -strict-sequence -ccopt -Ilib -package unix -package threads -package sexplib.syntax -package sexplib -package res -package pcre -package pa_pipebang -package pa_ounit -package fieldslib.syntax -package fieldslib -package core -package bin_prot.syntax -package bin_prot -package bigarray -syntax camlp4o -thread -I lib -o lib/bench.cmo lib/bench.ml File "lib/bench.ml", line 411, characters 53-59: Error: The function applied to this argument has type clock:[< `Cpu | `Wall ] -> run_count:int -> Test.t -> Result.Stat.t Core.Std.Array.t This argument cannot be applied with label ?clock ...which seems to be some changes in the handling of optional arguments vs 4.00.0. -anil From yury.sulsky at gmail.com Mon Jan 28 15:34:31 2013 From: yury.sulsky at gmail.com (Yury Sulsky) Date: Mon, 28 Jan 2013 10:34:31 -0500 Subject: Core_extended 4.01.0dev compilation failure In-Reply-To: References: Message-ID: Anil, thanks, that was clearly a mistake in the code. Apparently, at least before 4.01, it was possible to label non-optional arguments with the ``?arg'' syntax instead of ``~arg''. On Sun, Jan 27, 2013 at 5:38 AM, Anil Madhavapeddy wrote: > Just a headsup that Core_extended doesn't compile on 4.01.0dev: > > + ocamlfind ocamlc -c -g -w Aemr-28 -strict-sequence -ccopt -Ilib -package > unix -package threads -package sexplib.syntax -package sexplib -package res > -package pcre -package pa_pipebang -package pa_ounit -package > fieldslib.syntax -package fieldslib -package core -package bin_prot.syntax > -package bin_prot -package bigarray -syntax camlp4o -thread -I lib -o > lib/bench.cmo lib/bench.ml > > File "lib/bench.ml", line 411, characters 53-59: Error: The function > applied to this argument has type clock:[< `Cpu | `Wall ] -> run_count:int > -> Test.t -> Result.Stat.t Core.Std.Array.t This argument cannot be applied > with label ?clock > > ...which seems to be some changes in the handling of optional arguments vs > 4.00.0. > > -anil -- You received this message because you are subscribed to the Google Groups "ocaml-core" group. To unsubscribe from this group and stop receiving emails from it, send an email to ocaml-core+unsubscribe at googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ocaml-core at googlegroups.com Tue Jan 29 03:07:14 2013 From: ocaml-core at googlegroups.com (ocaml-core at googlegroups.com) Date: Tue, 29 Jan 2013 03:07:14 +0000 Subject: Moderator's spam report for ocaml-core@googlegroups.com Message-ID: <047d7b603e08c9246004d464b0bd@google.com> This message is being sent to you because you are a moderator of the group ocaml-core. The following suspicious messages were sent to your group, but are being held in your moderation queue because they are classified as likely spam messages. If you take no action, all the messages below will be discarded automatically as spam. However, if you see any messages that are not spam below, you may approve them individually by going to: http://groups.google.com/group/ocaml-core/pendmsg Please do not mark this notification as spam; this is a service for group moderators. If you do not wish to receive these notifications in the future, you may change your preferences by going to: http://groups.google.com/group/ocaml-core/manage_post ------- 1 of 3 ------- Subject: International exhibition for Clothes , Textile & accessories >From: "International exhibition" Date: Jan 27 05:47PM -0800 www.3gexpo.com 1. Name: International exhibition for Clothes , Textile & accessories . 2. Venue & Date: Jeddah, Saudi Arabia - From 16 : 19 June. 2013. 3. Application deadline: May .15. 2013. 4. Participation fees: $300 per sq/m Approve: http://groups.google.com/group/ocaml-core/pendmsg?view=full&pending_id=112378627561890927 ------- 2 of 3 ------- Subject: International exhibition for Clothes , Textile & accessories >From: "International exhibition" Date: Jan 27 05:51PM -0800 www.3gexpo.com 1. Name: International exhibition for Clothes , Textile & accessories . 2. Venue & Date: Jeddah, Saudi Arabia - From 16 : 19 June. 2013. 3. Application deadline: May .15. 2013. 4. Participation fees: $300 per sq/m Approve: http://groups.google.com/group/ocaml-core/pendmsg?view=full&pending_id=5878474451928616462 ------- 3 of 3 ------- Subject: Notice of Tax Return >From: "HMRC" Date: Jan 28 10:58AM +0100 www.hmrc.gov.uk Date 28 january 2013 Our Ref. C/048763/13 Your Ref. 10B/3455/13 NOTICE OF TAX RETURN FOR YEAR 2012 Dear Sir/Madam, I am sending this email to announce: After the last annual calculation of your fiscal activity we Approve: http://groups.google.com/group/ocaml-core/pendmsg?view=full&pending_id=8360168008716256018 For more information about this message, please visit: https://support.google.com/groups/bin/answer.py?hl=en&answer=47792 -- You received this message because you are subscribed to the Google Groups "ocaml-core" group. To unsubscribe from this group and stop receiving emails from it, send an email to ocaml-core+unsubscribe at googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. From bobzhang1988 at gmail.com Tue Jan 29 09:47:46 2013 From: bobzhang1988 at gmail.com (bob zhang) Date: Tue, 29 Jan 2013 04:47:46 -0500 Subject: Core_extended 4.01.0dev compilation failure In-Reply-To: References: Message-ID: Actually, it was a bug fix by Jacques On Mon, Jan 28, 2013 at 10:34 AM, Yury Sulsky wrote: > Anil, thanks, that was clearly a mistake in the code. Apparently, at least > before 4.01, it was possible to label non-optional arguments with the > ``?arg'' syntax instead of ``~arg''. > > > > On Sun, Jan 27, 2013 at 5:38 AM, Anil Madhavapeddy wrote: > >> Just a headsup that Core_extended doesn't compile on 4.01.0dev: >> >> + ocamlfind ocamlc -c -g -w Aemr-28 -strict-sequence -ccopt -Ilib >> -package unix -package threads -package sexplib.syntax -package sexplib >> -package res -package pcre -package pa_pipebang -package pa_ounit -package >> fieldslib.syntax -package fieldslib -package core -package bin_prot.syntax >> -package bin_prot -package bigarray -syntax camlp4o -thread -I lib -o >> lib/bench.cmo lib/bench.ml >> >> File "lib/bench.ml", line 411, characters 53-59: Error: The function >> applied to this argument has type clock:[< `Cpu | `Wall ] -> run_count:int >> -> Test.t -> Result.Stat.t Core.Std.Array.t This argument cannot be applied >> with label ?clock >> >> ...which seems to be some changes in the handling of optional arguments >> vs 4.00.0. >> >> -anil > > > -- > You received this message because you are subscribed to the Google Groups > "ocaml-core" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to ocaml-core+unsubscribe at googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. > > > -- Regards -- Bob -- You received this message because you are subscribed to the Google Groups "ocaml-core" group. To unsubscribe from this group and stop receiving emails from it, send an email to ocaml-core+unsubscribe at googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jdimino at janestreet.com Wed Jan 30 22:12:32 2013 From: jdimino at janestreet.com (Jeremie Dimino) Date: Wed, 30 Jan 2013 17:12:32 -0500 Subject: [ANN] Core Suite 109.07.00 released Message-ID: I'm pleased to announce the 109.07.00 release of the Core suite of libraries. Core is an industrial strength alternative to OCaml's standard library. Tarballs can be found here: https://ocaml.janestreet.com/ocaml-core/109.07.00/individual/ And the documentation: https://ocaml.janestreet.com/ocaml-core/109.07.00/doc/ All packages are available through opam. ** The Core suite ** The Core suite includes a variety of useful libraries, including: - Core: the heart of the standard library. - Several useful syntax extensions - type-conv: a library for building type-driven syntax extensions - sexplib: a library for handling s-expressions, and a syntax extension for auto-generating conversions between OCaml types and s-expressions - bin-prot: a syntax-extensions for generating - pipebang - variantslib - comparelib - fieldslib - Async: a monadic concurrency library. - Core_extended: extra components that are not as closely vetted or as stable as Core. This includes, Shell, an interface for interacting with the UNIX shell, and Command, a command-line parsing library. ** Repositories ** The official repositories for the Core libraries are now located on the "janestreet" organisation on github and the "janestreet" team on bitbucket. github: https://github.com/janestreet bitbucket: https://bitbucket.org/janestreet github home page: http://janestreet.github.com/ We changed the way we are exporting our source tree; there will now be only one visible commit per release and project. Hopefully this simpiflied process will allow more frequent updates. ** Contribution ** If you want to contribute to core the preferred way is to submit a pull-request, which won't be merged in the end but will be used for working on the changes before they are accepted and added to our development process for integration in a future release. ** Changes ** He is a list of changes since the previous public release (108.08.00): - Switched to OCaml 4.0. - Async: - Add a [~perm] argument to [Writer.open_file] to set the file permissions in the same way [Unix.openfile] does. - Added [Async.Unix.unsetenv]. - Fixed a bug in [Reader] that in some situations would make the reader unusable after an error in user code (e.g. a failed sexp conversion). - Fixed a bug in [Writer] that manifests when scheduling bigstrings with non-zero pos parameter. - Fixed a bug in [Scheduler.go], which previously behaved incorrectly if an exception had been raised to the main monitor prior to [Scheduler.go] being called. The exception is now dealt with immediately, rather than running a cycle. - Exposed the type and value [Async.Config.t] as sexpable. - Improved error message when a user requests async to manage a file descriptor that it is already managing. - Improved error message when creation of the async scheduler fails. - Added [val _squelch_unused_module_warning_] to [Async.Std]. - Made [Reader.load_sexp{,s}] handle exceptions other than [Of_sexp_error]. - Fixed a bug in async's handing of file descriptors -- a missed check for a file descriptor having been closed. - Added [Writer.set_buffer_age_limit]. - Improved the performance of [Deferred.Queue] by changing the implementation to use lists rather than arrays, which reduces gc promotion. - Added [?should_close_file_descriptor:bool] argument to [Async.Unix.close]. - Moved the implementation of finalizers from Async_unix to Async_core. This makes it possible to unit test finalizers (and things using them) using only the Async_core scheduler. - Changed the async scheduler so that if there are no upcoming events, it times out in 50ms rather than waiting forever. - Added =Monad_sequence.iteri=, which in turn adds it to: =Deferred.Array=, =Deferred.List=, and =Deferred.Queue=. - Added =Pipe.init=, which is analogous to =Deferred.create=. - Improved the performance of =Pipe.iter{,_without_pushback}=. - Improved =Reader.read_one_chunk_at_a_time_until_eof=: - the callback need not consume everything - add =`Eof_with_unconsumed_data= as a possible result - grow internal buffer of the reader when needed - Added =Shutdown.exit=, removed =Shutdown.shutdown_and_raise=. - Added =Scheduler.force_current_cycle_to_end=. - Core: - Added [Char.of_string]. - Fix [Backtrace.get], which was broken in 109.00, with the switch to OCaml 4.0. - Added [Heap.iter_el]. - Updated [Core.Unix.stat] so that access, modify, and change times have nanosecond precision. - Fixed a bug in [Nano_mutex.invariant]. - Simplified the implementation of [with_return] using a local explicit polymorphic type variable. - Added [Map.symmetric_diff], for returning a list of differences between two maps. It has a fast-path implementation for maps that share a large amount of their internal structure. - Added a number of functions to =Bounded_int_table=: =equal=, =exists{,i}=, =for_all{,i}=, =filter_map{,i}=, =map{,i}=. Also added a functor, =Bounded_int_table.With_key=, that makes a bounded-int table binable and sexpable, and adds =of_alist= and =of_alist_exn=. - Added =Doubly_linked.iter_elt= and =Bag.iter_elt=. - Added =module Invariant=, which defines signatures that are to be included in other signatures to ensure a consistent interface to invariant-style functions. - Added =module Ordering=, which defines: =type t = Less | Equal | Greater= -- Jeremie Dimino, for the Core team -- You received this message because you are subscribed to the Google Groups "ocaml-core" group. To unsubscribe from this group and stop receiving emails from it, send an email to ocaml-core+unsubscribe at googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. From yminsky at janestreet.com Thu Jan 31 01:07:06 2013 From: yminsky at janestreet.com (Yaron Minsky) Date: Wed, 30 Jan 2013 20:07:06 -0500 Subject: [ANN] Core Suite 109.07.00 released In-Reply-To: <632F0809-EABE-47DA-80B5-E6509E489DCF@recoil.org> References: <632F0809-EABE-47DA-80B5-E6509E489DCF@recoil.org> Message-ID: On Wed, Jan 30, 2013 at 7:37 PM, Anil Madhavapeddy wrote: > [-ocaml list] > > A few incompatibilities so far: > > - MacOS X broken due to configuration errors: > https://github.com/janestreet/core/pull/1 > > - Warnings-as-errors enabled in release tarballs, which needs to be disabled > https://github.com/OCamlPro/opam-repository/issues/353 Eeek. Looks like we need to tune our process just a bit. > - This is all intended to be 4.00.0+ only, right? I've added a version > constraint on type_conv which breaks on 3.12.1 atm. Yes, this is 4.00 only. 109 is where we stopped support 3.12.1. y > -anil > > On 30 Jan 2013, at 22:12, Jeremie Dimino wrote: > >> I'm pleased to announce the 109.07.00 release of the Core suite of >> libraries. Core is an industrial strength alternative to OCaml's >> standard library. >> >> Tarballs can be found here: >> >> https://ocaml.janestreet.com/ocaml-core/109.07.00/individual/ >> >> And the documentation: >> >> https://ocaml.janestreet.com/ocaml-core/109.07.00/doc/ >> >> All packages are available through opam. >> >> ** The Core suite ** >> >> The Core suite includes a variety of useful libraries, including: >> >> - Core: the heart of the standard library. >> - Several useful syntax extensions >> - type-conv: a library for building type-driven syntax extensions >> - sexplib: a library for handling s-expressions, and a syntax >> extension for auto-generating conversions between OCaml types and >> s-expressions >> - bin-prot: a syntax-extensions for generating >> - pipebang >> - variantslib >> - comparelib >> - fieldslib >> - Async: a monadic concurrency library. >> - Core_extended: extra components that are not as closely vetted or as >> stable as Core. This includes, Shell, an interface for interacting >> with the UNIX shell, and Command, a command-line parsing library. >> >> ** Repositories ** >> >> The official repositories for the Core libraries are now located on >> the "janestreet" organisation on github and the "janestreet" team on >> bitbucket. >> >> github: https://github.com/janestreet >> bitbucket: https://bitbucket.org/janestreet >> github home page: http://janestreet.github.com/ >> >> We changed the way we are exporting our source tree; there will now be >> only one visible commit per release and project. Hopefully this >> simpiflied process will allow more frequent updates. >> >> ** Contribution ** >> >> If you want to contribute to core the preferred way is to submit a >> pull-request, which won't be merged in the end but will be used for >> working on the changes before they are accepted and added to our >> development process for integration in a future release. >> >> ** Changes ** >> >> He is a list of changes since the previous public release (108.08.00): >> >> - Switched to OCaml 4.0. >> - Async: >> - Add a [~perm] argument to [Writer.open_file] to set the file >> permissions in the same way [Unix.openfile] does. >> - Added [Async.Unix.unsetenv]. >> - Fixed a bug in [Reader] that in some situations would make the >> reader unusable after an error in user code (e.g. a failed sexp >> conversion). >> - Fixed a bug in [Writer] that manifests when scheduling bigstrings >> with non-zero pos parameter. >> - Fixed a bug in [Scheduler.go], which previously behaved incorrectly >> if an exception had been raised to the main monitor prior to >> [Scheduler.go] being called. The exception is now dealt with >> immediately, rather than running a cycle. >> - Exposed the type and value [Async.Config.t] as sexpable. >> - Improved error message when a user requests async to manage a file >> descriptor that it is already managing. >> - Improved error message when creation of the async scheduler fails. >> - Added [val _squelch_unused_module_warning_] to [Async.Std]. >> - Made [Reader.load_sexp{,s}] handle exceptions other than >> [Of_sexp_error]. >> - Fixed a bug in async's handing of file descriptors -- a missed check >> for a file descriptor having been closed. >> - Added [Writer.set_buffer_age_limit]. >> - Improved the performance of [Deferred.Queue] by changing the >> implementation to use lists rather than arrays, which reduces gc >> promotion. >> - Added [?should_close_file_descriptor:bool] argument to [Async.Unix.close]. >> - Moved the implementation of finalizers from Async_unix to >> Async_core. This makes it possible to unit test finalizers (and >> things using them) using only the Async_core scheduler. >> - Changed the async scheduler so that if there are no upcoming events, >> it times out in 50ms rather than waiting forever. >> - Added =Monad_sequence.iteri=, which in turn adds it to: >> =Deferred.Array=, =Deferred.List=, and =Deferred.Queue=. >> - Added =Pipe.init=, which is analogous to =Deferred.create=. >> - Improved the performance of =Pipe.iter{,_without_pushback}=. >> - Improved =Reader.read_one_chunk_at_a_time_until_eof=: >> - the callback need not consume everything >> - add =`Eof_with_unconsumed_data= as a possible result >> - grow internal buffer of the reader when needed >> - Added =Shutdown.exit=, removed =Shutdown.shutdown_and_raise=. >> - Added =Scheduler.force_current_cycle_to_end=. >> - Core: >> - Added [Char.of_string]. >> - Fix [Backtrace.get], which was broken in 109.00, with the >> switch to OCaml 4.0. >> - Added [Heap.iter_el]. >> - Updated [Core.Unix.stat] so that access, modify, and change times >> have nanosecond precision. >> - Fixed a bug in [Nano_mutex.invariant]. >> - Simplified the implementation of [with_return] using a local >> explicit polymorphic type variable. >> - Added [Map.symmetric_diff], for returning a list of differences >> between two maps. It has a fast-path implementation for maps that >> share a large amount of their internal structure. >> - Added a number of functions to =Bounded_int_table=: =equal=, >> =exists{,i}=, =for_all{,i}=, =filter_map{,i}=, =map{,i}=. Also >> added a functor, =Bounded_int_table.With_key=, that makes a >> bounded-int table binable and sexpable, and adds =of_alist= and >> =of_alist_exn=. >> - Added =Doubly_linked.iter_elt= and =Bag.iter_elt=. >> - Added =module Invariant=, which defines signatures that are to >> be included in other signatures to ensure a consistent interface to >> invariant-style functions. >> - Added =module Ordering=, which defines: >> =type t = Less | Equal | Greater= >> >> -- >> Jeremie Dimino, for the Core team >> >> -- >> You received this message because you are subscribed to the Google Groups "ocaml-core" group. >> To unsubscribe from this group and stop receiving emails from it, send an email to ocaml-core+unsubscribe at googlegroups.com. >> For more options, visit https://groups.google.com/groups/opt_out. >> >> > > -- > You received this message because you are subscribed to the Google Groups "ocaml-core" group. > To unsubscribe from this group and stop receiving emails from it, send an email to ocaml-core+unsubscribe at googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. > > -- You received this message because you are subscribed to the Google Groups "ocaml-core" group. To unsubscribe from this group and stop receiving emails from it, send an email to ocaml-core+unsubscribe at googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. From anil at recoil.org Thu Jan 31 00:37:20 2013 From: anil at recoil.org (Anil Madhavapeddy) Date: Thu, 31 Jan 2013 00:37:20 +0000 Subject: [ANN] Core Suite 109.07.00 released In-Reply-To: References: Message-ID: <632F0809-EABE-47DA-80B5-E6509E489DCF@recoil.org> [-ocaml list] A few incompatibilities so far: - MacOS X broken due to configuration errors: https://github.com/janestreet/core/pull/1 - Warnings-as-errors enabled in release tarballs, which needs to be disabled https://github.com/OCamlPro/opam-repository/issues/353 - This is all intended to be 4.00.0+ only, right? I've added a version constraint on type_conv which breaks on 3.12.1 atm. -anil On 30 Jan 2013, at 22:12, Jeremie Dimino wrote: > I'm pleased to announce the 109.07.00 release of the Core suite of > libraries. Core is an industrial strength alternative to OCaml's > standard library. > > Tarballs can be found here: > > https://ocaml.janestreet.com/ocaml-core/109.07.00/individual/ > > And the documentation: > > https://ocaml.janestreet.com/ocaml-core/109.07.00/doc/ > > All packages are available through opam. > > ** The Core suite ** > > The Core suite includes a variety of useful libraries, including: > > - Core: the heart of the standard library. > - Several useful syntax extensions > - type-conv: a library for building type-driven syntax extensions > - sexplib: a library for handling s-expressions, and a syntax > extension for auto-generating conversions between OCaml types and > s-expressions > - bin-prot: a syntax-extensions for generating > - pipebang > - variantslib > - comparelib > - fieldslib > - Async: a monadic concurrency library. > - Core_extended: extra components that are not as closely vetted or as > stable as Core. This includes, Shell, an interface for interacting > with the UNIX shell, and Command, a command-line parsing library. > > ** Repositories ** > > The official repositories for the Core libraries are now located on > the "janestreet" organisation on github and the "janestreet" team on > bitbucket. > > github: https://github.com/janestreet > bitbucket: https://bitbucket.org/janestreet > github home page: http://janestreet.github.com/ > > We changed the way we are exporting our source tree; there will now be > only one visible commit per release and project. Hopefully this > simpiflied process will allow more frequent updates. > > ** Contribution ** > > If you want to contribute to core the preferred way is to submit a > pull-request, which won't be merged in the end but will be used for > working on the changes before they are accepted and added to our > development process for integration in a future release. > > ** Changes ** > > He is a list of changes since the previous public release (108.08.00): > > - Switched to OCaml 4.0. > - Async: > - Add a [~perm] argument to [Writer.open_file] to set the file > permissions in the same way [Unix.openfile] does. > - Added [Async.Unix.unsetenv]. > - Fixed a bug in [Reader] that in some situations would make the > reader unusable after an error in user code (e.g. a failed sexp > conversion). > - Fixed a bug in [Writer] that manifests when scheduling bigstrings > with non-zero pos parameter. > - Fixed a bug in [Scheduler.go], which previously behaved incorrectly > if an exception had been raised to the main monitor prior to > [Scheduler.go] being called. The exception is now dealt with > immediately, rather than running a cycle. > - Exposed the type and value [Async.Config.t] as sexpable. > - Improved error message when a user requests async to manage a file > descriptor that it is already managing. > - Improved error message when creation of the async scheduler fails. > - Added [val _squelch_unused_module_warning_] to [Async.Std]. > - Made [Reader.load_sexp{,s}] handle exceptions other than > [Of_sexp_error]. > - Fixed a bug in async's handing of file descriptors -- a missed check > for a file descriptor having been closed. > - Added [Writer.set_buffer_age_limit]. > - Improved the performance of [Deferred.Queue] by changing the > implementation to use lists rather than arrays, which reduces gc > promotion. > - Added [?should_close_file_descriptor:bool] argument to [Async.Unix.close]. > - Moved the implementation of finalizers from Async_unix to > Async_core. This makes it possible to unit test finalizers (and > things using them) using only the Async_core scheduler. > - Changed the async scheduler so that if there are no upcoming events, > it times out in 50ms rather than waiting forever. > - Added =Monad_sequence.iteri=, which in turn adds it to: > =Deferred.Array=, =Deferred.List=, and =Deferred.Queue=. > - Added =Pipe.init=, which is analogous to =Deferred.create=. > - Improved the performance of =Pipe.iter{,_without_pushback}=. > - Improved =Reader.read_one_chunk_at_a_time_until_eof=: > - the callback need not consume everything > - add =`Eof_with_unconsumed_data= as a possible result > - grow internal buffer of the reader when needed > - Added =Shutdown.exit=, removed =Shutdown.shutdown_and_raise=. > - Added =Scheduler.force_current_cycle_to_end=. > - Core: > - Added [Char.of_string]. > - Fix [Backtrace.get], which was broken in 109.00, with the > switch to OCaml 4.0. > - Added [Heap.iter_el]. > - Updated [Core.Unix.stat] so that access, modify, and change times > have nanosecond precision. > - Fixed a bug in [Nano_mutex.invariant]. > - Simplified the implementation of [with_return] using a local > explicit polymorphic type variable. > - Added [Map.symmetric_diff], for returning a list of differences > between two maps. It has a fast-path implementation for maps that > share a large amount of their internal structure. > - Added a number of functions to =Bounded_int_table=: =equal=, > =exists{,i}=, =for_all{,i}=, =filter_map{,i}=, =map{,i}=. Also > added a functor, =Bounded_int_table.With_key=, that makes a > bounded-int table binable and sexpable, and adds =of_alist= and > =of_alist_exn=. > - Added =Doubly_linked.iter_elt= and =Bag.iter_elt=. > - Added =module Invariant=, which defines signatures that are to > be included in other signatures to ensure a consistent interface to > invariant-style functions. > - Added =module Ordering=, which defines: > =type t = Less | Equal | Greater= > > -- > Jeremie Dimino, for the Core team > > -- > You received this message because you are subscribed to the Google Groups "ocaml-core" group. > To unsubscribe from this group and stop receiving emails from it, send an email to ocaml-core+unsubscribe at googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. > > -- You received this message because you are subscribed to the Google Groups "ocaml-core" group. To unsubscribe from this group and stop receiving emails from it, send an email to ocaml-core+unsubscribe at googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. From anil at recoil.org Thu Jan 31 10:26:18 2013 From: anil at recoil.org (Anil Madhavapeddy) Date: Thu, 31 Jan 2013 10:26:18 +0000 Subject: [ANN] Core Suite 109.07.00 released In-Reply-To: References: <632F0809-EABE-47DA-80B5-E6509E489DCF@recoil.org> Message-ID: <55EB08B7-A669-4D5C-B070-0C25BD0FAA60@recoil.org> On 31 Jan 2013, at 01:07, Yaron Minsky wrote: > On Wed, Jan 30, 2013 at 7:37 PM, Anil Madhavapeddy wrote: >> [-ocaml list] >> >> A few incompatibilities so far: >> >> - MacOS X broken due to configuration errors: >> https://github.com/janestreet/core/pull/1 >> >> - Warnings-as-errors enabled in release tarballs, which needs to be disabled >> https://github.com/OCamlPro/opam-repository/issues/353 > > Eeek. Looks like we need to tune our process just a bit. > >> - This is all intended to be 4.00.0+ only, right? I've added a version >> constraint on type_conv which breaks on 3.12.1 atm. > > Yes, this is 4.00 only. 109 is where we stopped support 3.12.1. I've pushed a temporary fix to OPAM to restrict the 109.* versions to be selected on Linux only, which at least lets me get my MacOS X development environment back. Finer grain constraints are possible but put a strain on the solver, which Thomas is currently looking at. Jeremie, we can also hook up the OPAM test setup to test a pull request before merge. We should probably do this before any future upgrades. One way to do this is for you to tag an ~rc1 to the version (which will be ordered correctly by the version comparator). If it passes, you can just re-tag on your end to the final version, and it can be merged without further tests. -anil -- You received this message because you are subscribed to the Google Groups "ocaml-core" group. To unsubscribe from this group and stop receiving emails from it, send an email to ocaml-core+unsubscribe at googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. From anil at recoil.org Thu Jan 31 10:45:15 2013 From: anil at recoil.org (Anil Madhavapeddy) Date: Thu, 31 Jan 2013 10:45:15 +0000 Subject: [ANN] Core Suite 109.07.00 released In-Reply-To: References: <632F0809-EABE-47DA-80B5-E6509E489DCF@recoil.org> <55EB08B7-A669-4D5C-B070-0C25BD0FAA60@recoil.org> Message-ID: On 31 Jan 2013, at 10:42, Sylvain Le Gall wrote: > > I tend to do things the other way: > - have a builder (I use jenkins) > - if the build and every tests succeed, provide enough information in a file called dist/tag (e.g. the checksum of HEAD for git, or a patch for darcs) > - when ready, just wget the latest successful dist/tag and use it to tag your tree > - if needed use a matrix project to build on different system (Mac OS X, Debian Squeeze 32bits, Debian Squeeze 64 bits, Windows), the success of the build in this case will be linked to the success of every platform That's not compatible with the Jane Street release process. They have to push an RC to OPAM for us to be able to kick off tests. -anil -- You received this message because you are subscribed to the Google Groups "ocaml-core" group. To unsubscribe from this group and stop receiving emails from it, send an email to ocaml-core+unsubscribe at googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. From markus.mottl at gmail.com Thu Jan 31 16:14:46 2013 From: markus.mottl at gmail.com (Markus Mottl) Date: Thu, 31 Jan 2013 11:14:46 -0500 Subject: [ANN] Core Suite 109.07.00 released In-Reply-To: References: Message-ID: Btw., I like the new repository setup better than the previous one. I think keeping sub-projects separate instead of having one giant "core" project will make it more manageable to keep track of contributions. Using the pull request feature instead of patches to the mailing list should also help make the contribution process more efficient and transparent. Thanks! On Wed, Jan 30, 2013 at 5:12 PM, Jeremie Dimino wrote: > I'm pleased to announce the 109.07.00 release of the Core suite of > libraries. Core is an industrial strength alternative to OCaml's > standard library. > > Tarballs can be found here: > > https://ocaml.janestreet.com/ocaml-core/109.07.00/individual/ > > And the documentation: > > https://ocaml.janestreet.com/ocaml-core/109.07.00/doc/ > > All packages are available through opam. > > ** The Core suite ** > > The Core suite includes a variety of useful libraries, including: > > - Core: the heart of the standard library. > - Several useful syntax extensions > - type-conv: a library for building type-driven syntax extensions > - sexplib: a library for handling s-expressions, and a syntax > extension for auto-generating conversions between OCaml types and > s-expressions > - bin-prot: a syntax-extensions for generating > - pipebang > - variantslib > - comparelib > - fieldslib > - Async: a monadic concurrency library. > - Core_extended: extra components that are not as closely vetted or as > stable as Core. This includes, Shell, an interface for interacting > with the UNIX shell, and Command, a command-line parsing library. > > ** Repositories ** > > The official repositories for the Core libraries are now located on > the "janestreet" organisation on github and the "janestreet" team on > bitbucket. > > github: https://github.com/janestreet > bitbucket: https://bitbucket.org/janestreet > github home page: http://janestreet.github.com/ > > We changed the way we are exporting our source tree; there will now be > only one visible commit per release and project. Hopefully this > simpiflied process will allow more frequent updates. > > ** Contribution ** > > If you want to contribute to core the preferred way is to submit a > pull-request, which won't be merged in the end but will be used for > working on the changes before they are accepted and added to our > development process for integration in a future release. > > ** Changes ** > > He is a list of changes since the previous public release (108.08.00): > > - Switched to OCaml 4.0. > - Async: > - Add a [~perm] argument to [Writer.open_file] to set the file > permissions in the same way [Unix.openfile] does. > - Added [Async.Unix.unsetenv]. > - Fixed a bug in [Reader] that in some situations would make the > reader unusable after an error in user code (e.g. a failed sexp > conversion). > - Fixed a bug in [Writer] that manifests when scheduling bigstrings > with non-zero pos parameter. > - Fixed a bug in [Scheduler.go], which previously behaved incorrectly > if an exception had been raised to the main monitor prior to > [Scheduler.go] being called. The exception is now dealt with > immediately, rather than running a cycle. > - Exposed the type and value [Async.Config.t] as sexpable. > - Improved error message when a user requests async to manage a file > descriptor that it is already managing. > - Improved error message when creation of the async scheduler fails. > - Added [val _squelch_unused_module_warning_] to [Async.Std]. > - Made [Reader.load_sexp{,s}] handle exceptions other than > [Of_sexp_error]. > - Fixed a bug in async's handing of file descriptors -- a missed check > for a file descriptor having been closed. > - Added [Writer.set_buffer_age_limit]. > - Improved the performance of [Deferred.Queue] by changing the > implementation to use lists rather than arrays, which reduces gc > promotion. > - Added [?should_close_file_descriptor:bool] argument to [Async.Unix.close]. > - Moved the implementation of finalizers from Async_unix to > Async_core. This makes it possible to unit test finalizers (and > things using them) using only the Async_core scheduler. > - Changed the async scheduler so that if there are no upcoming events, > it times out in 50ms rather than waiting forever. > - Added =Monad_sequence.iteri=, which in turn adds it to: > =Deferred.Array=, =Deferred.List=, and =Deferred.Queue=. > - Added =Pipe.init=, which is analogous to =Deferred.create=. > - Improved the performance of =Pipe.iter{,_without_pushback}=. > - Improved =Reader.read_one_chunk_at_a_time_until_eof=: > - the callback need not consume everything > - add =`Eof_with_unconsumed_data= as a possible result > - grow internal buffer of the reader when needed > - Added =Shutdown.exit=, removed =Shutdown.shutdown_and_raise=. > - Added =Scheduler.force_current_cycle_to_end=. > - Core: > - Added [Char.of_string]. > - Fix [Backtrace.get], which was broken in 109.00, with the > switch to OCaml 4.0. > - Added [Heap.iter_el]. > - Updated [Core.Unix.stat] so that access, modify, and change times > have nanosecond precision. > - Fixed a bug in [Nano_mutex.invariant]. > - Simplified the implementation of [with_return] using a local > explicit polymorphic type variable. > - Added [Map.symmetric_diff], for returning a list of differences > between two maps. It has a fast-path implementation for maps that > share a large amount of their internal structure. > - Added a number of functions to =Bounded_int_table=: =equal=, > =exists{,i}=, =for_all{,i}=, =filter_map{,i}=, =map{,i}=. Also > added a functor, =Bounded_int_table.With_key=, that makes a > bounded-int table binable and sexpable, and adds =of_alist= and > =of_alist_exn=. > - Added =Doubly_linked.iter_elt= and =Bag.iter_elt=. > - Added =module Invariant=, which defines signatures that are to > be included in other signatures to ensure a consistent interface to > invariant-style functions. > - Added =module Ordering=, which defines: > =type t = Less | Equal | Greater= > > -- > Jeremie Dimino, for the Core team > > -- > You received this message because you are subscribed to the Google Groups "ocaml-core" group. > To unsubscribe from this group and stop receiving emails from it, send an email to ocaml-core+unsubscribe at googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. > > -- Markus Mottl http://www.ocaml.info markus.mottl at gmail.com -- You received this message because you are subscribed to the Google Groups "ocaml-core" group. To unsubscribe from this group and stop receiving emails from it, send an email to ocaml-core+unsubscribe at googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. From jdimino at janestreet.com Thu Jan 31 16:37:42 2013 From: jdimino at janestreet.com (Jeremie Dimino) Date: Thu, 31 Jan 2013 11:37:42 -0500 Subject: [ANN] Core Suite 109.07.00 released In-Reply-To: <632F0809-EABE-47DA-80B5-E6509E489DCF@recoil.org> References: <632F0809-EABE-47DA-80B5-E6509E489DCF@recoil.org> Message-ID: On Wed, Jan 30, 2013 at 7:37 PM, Anil Madhavapeddy wrote: > - MacOS X broken due to configuration errors: > https://github.com/janestreet/core/pull/1 I'll try to fix this. > - Warnings-as-errors enabled in release tarballs, which needs to be disabled > https://github.com/OCamlPro/opam-repository/issues/353 It will be disabled in the next release. For now I added patches in opam packages to disable -warn-error. -- You received this message because you are subscribed to the Google Groups "ocaml-core" group. To unsubscribe from this group and stop receiving emails from it, send an email to ocaml-core+unsubscribe at googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. From sylvain at le-gall.net Thu Jan 31 10:42:02 2013 From: sylvain at le-gall.net (Sylvain Le Gall) Date: Thu, 31 Jan 2013 11:42:02 +0100 Subject: [ANN] Core Suite 109.07.00 released In-Reply-To: <55EB08B7-A669-4D5C-B070-0C25BD0FAA60@recoil.org> References: <632F0809-EABE-47DA-80B5-E6509E489DCF@recoil.org> <55EB08B7-A669-4D5C-B070-0C25BD0FAA60@recoil.org> Message-ID: 2013/1/31 Anil Madhavapeddy > On 31 Jan 2013, at 01:07, Yaron Minsky wrote: > > > On Wed, Jan 30, 2013 at 7:37 PM, Anil Madhavapeddy > wrote: > >> [-ocaml list] > >> > >> A few incompatibilities so far: > >> > >> - MacOS X broken due to configuration errors: > >> https://github.com/janestreet/core/pull/1 > >> > >> - Warnings-as-errors enabled in release tarballs, which needs to be > disabled > >> https://github.com/OCamlPro/opam-repository/issues/353 > > > > Eeek. Looks like we need to tune our process just a bit. > > > >> - This is all intended to be 4.00.0+ only, right? I've added a version > >> constraint on type_conv which breaks on 3.12.1 atm. > > > > Yes, this is 4.00 only. 109 is where we stopped support 3.12.1. > > I've pushed a temporary fix to OPAM to restrict the 109.* versions to > be selected on Linux only, which at least lets me get my MacOS X > development > environment back. > > Finer grain constraints are possible but put a strain on the solver, which > Thomas is currently looking at. > > Jeremie, we can also hook up the OPAM test setup to test a pull request > before > merge. We should probably do this before any future upgrades. One way to > do > this is for you to tag an ~rc1 to the version (which will be ordered > correctly > by the version comparator). If it passes, you can just re-tag on your end > to > the final version, and it can be merged without further tests. I tend to do things the other way: - have a builder (I use jenkins) - if the build and every tests succeed, provide enough information in a file called dist/tag (e.g. the checksum of HEAD for git, or a patch for darcs) - when ready, just wget the latest successful dist/tag and use it to tag your tree - if needed use a matrix project to build on different system (Mac OS X, Debian Squeeze 32bits, Debian Squeeze 64 bits, Windows), the success of the build in this case will be linked to the success of every platform i.e. you always tests everything using jenkins and you always provide information to tag. This allows to be always ready to do a release... Example: http://deci.ovh.le-gall.net:8080/job/gildor478-oasis/lastSuccessfulBuild/artifact/dist/tag browse: http://deci.ovh.le-gall.net:8080/job/gildor478-oasis/ Regards Sylvain -- You received this message because you are subscribed to the Google Groups "ocaml-core" group. To unsubscribe from this group and stop receiving emails from it, send an email to ocaml-core+unsubscribe at googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sylvain at le-gall.net Thu Jan 31 11:04:50 2013 From: sylvain at le-gall.net (Sylvain Le Gall) Date: Thu, 31 Jan 2013 12:04:50 +0100 Subject: [ANN] Core Suite 109.07.00 released In-Reply-To: References: <632F0809-EABE-47DA-80B5-E6509E489DCF@recoil.org> <55EB08B7-A669-4D5C-B070-0C25BD0FAA60@recoil.org> Message-ID: 2013/1/31 Anil Madhavapeddy > On 31 Jan 2013, at 10:42, Sylvain Le Gall wrote: > > > > I tend to do things the other way: > > - have a builder (I use jenkins) > > - if the build and every tests succeed, provide enough information in a > file called dist/tag (e.g. the checksum of HEAD for git, or a patch for > darcs) > > - when ready, just wget the latest successful dist/tag and use it to tag > your tree > > - if needed use a matrix project to build on different system (Mac OS X, > Debian Squeeze 32bits, Debian Squeeze 64 bits, Windows), the success of the > build in this case will be linked to the success of every platform > > That's not compatible with the Jane Street release process. They have to > push an RC to OPAM for us to be able to kick off tests. > I probably have missed a couple of email about JS release process... ;-) Note that this way of doing thing doesn't prevent to use the dist/tag to tag a RC rather than doing a public release. > > -anil > > -- > You received this message because you are subscribed to the Google Groups > "ocaml-core" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to ocaml-core+unsubscribe at googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. > > > -- You received this message because you are subscribed to the Google Groups "ocaml-core" group. To unsubscribe from this group and stop receiving emails from it, send an email to ocaml-core+unsubscribe at googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -------------- next part -------------- An HTML attachment was scrubbed... URL: From francois.berenger.working at gmail.com Fri Jan 4 02:41:37 2013 From: francois.berenger.working at gmail.com (Francois Berenger) Date: Thu, 3 Jan 2013 18:41:37 -0800 (PST) Subject: randomizing a list Message-ID: <39b640ef-4394-4f06-b5a0-b51d4dc4ff23@googlegroups.com> Hello, What's the standard way to randomize the order of elements in a list? Thanks and happy new year! F. -------------- next part -------------- An HTML attachment was scrubbed... URL: From francois.berenger.working at gmail.com Fri Jan 4 04:03:27 2013 From: francois.berenger.working at gmail.com (Francois Berenger) Date: Thu, 3 Jan 2013 20:03:27 -0800 (PST) Subject: randomizing a list In-Reply-To: <39b640ef-4394-4f06-b5a0-b51d4dc4ff23@googlegroups.com> References: <39b640ef-4394-4f06-b5a0-b51d4dc4ff23@googlegroups.com> Message-ID: <5f50efbf-01e3-4e91-909d-6a70243900cc@googlegroups.com> I did this: (* return a randomized version of l *) let randomize l = let random_cmp x y = if x = y then 0 else if Random.bool() then 1 else -1 in List.sort random_cmp l Looks like it does what I want (I don't do crypto). On Friday, January 4, 2013 11:41:37 AM UTC+9, Francois Berenger wrote: > > Hello, > > What's the standard way to randomize the order > of elements in a list? > > Thanks and happy new year! > F. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From francois.berenger.working at gmail.com Fri Jan 4 04:10:09 2013 From: francois.berenger.working at gmail.com (Francois Berenger) Date: Thu, 3 Jan 2013 20:10:09 -0800 (PST) Subject: randomizing a list In-Reply-To: References: <39b640ef-4394-4f06-b5a0-b51d4dc4ff23@googlegroups.com> Message-ID: <6898abd7-bf2e-4897-9b6e-24a97ed55690@googlegroups.com> Thanks! I'll use these. I searched without success the keyword "shuffle" in Core's ocamldoc. I really wish there would be a search engine for Core (and all OCaml libraries in fact) ... By type, I'm pretty sure I would have found what I was looking for. On Friday, January 4, 2013 12:05:36 PM UTC+9, Yaron Minsky wrote: > > I would try List.permute or Array.permute in Core. > > y > > On Thu, Jan 3, 2013 at 9:49 PM, Sean McLaughlin > > wrote: > > http://en.wikipedia.org/wiki/Fisher%E2%80%93Yates_shuffle > > > > I'd implement this and do Array.to_list . shuffle . Array.of_list. > > > > > > > > On Thu, Jan 3, 2013 at 9:41 PM, Francois Berenger > > > wrote: > >> > >> Hello, > >> > >> What's the standard way to randomize the order > >> of elements in a list? > >> > >> Thanks and happy new year! > >> F. > >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From francois.berenger.working at gmail.com Fri Jan 4 04:37:26 2013 From: francois.berenger.working at gmail.com (Francois Berenger) Date: Thu, 3 Jan 2013 20:37:26 -0800 (PST) Subject: randomizing a list In-Reply-To: <6898abd7-bf2e-4897-9b6e-24a97ed55690@googlegroups.com> References: <39b640ef-4394-4f06-b5a0-b51d4dc4ff23@googlegroups.com> <6898abd7-bf2e-4897-9b6e-24a97ed55690@googlegroups.com> Message-ID: On Friday, January 4, 2013 1:10:09 PM UTC+9, Francois Berenger wrote: > > Thanks! I'll use these. > > I searched without success the keyword "shuffle" in Core's ocamldoc. > > I really wish there would be a search engine for Core (and all OCaml > libraries in fact) ... > By type, I'm pretty sure I would have found what I was looking for. > Or maybe I should just use Google? site:https://ocaml.janestreet.com/ocaml-core/latest/doc/ "'a list -> 'a list" random Gives permute as the first result. Amazing! :) > > On Friday, January 4, 2013 12:05:36 PM UTC+9, Yaron Minsky wrote: >> >> I would try List.permute or Array.permute in Core. >> >> y >> >> On Thu, Jan 3, 2013 at 9:49 PM, Sean McLaughlin >> wrote: >> > http://en.wikipedia.org/wiki/Fisher%E2%80%93Yates_shuffle >> > >> > I'd implement this and do Array.to_list . shuffle . Array.of_list. >> > >> > >> > >> > On Thu, Jan 3, 2013 at 9:41 PM, Francois Berenger >> > wrote: >> >> >> >> Hello, >> >> >> >> What's the standard way to randomize the order >> >> of elements in a list? >> >> >> >> Thanks and happy new year! >> >> F. >> >> >> > >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From seanmcl at gmail.com Fri Jan 4 02:49:43 2013 From: seanmcl at gmail.com (Sean McLaughlin) Date: Thu, 3 Jan 2013 21:49:43 -0500 Subject: randomizing a list In-Reply-To: <39b640ef-4394-4f06-b5a0-b51d4dc4ff23@googlegroups.com> References: <39b640ef-4394-4f06-b5a0-b51d4dc4ff23@googlegroups.com> Message-ID: http://en.wikipedia.org/wiki/Fisher%E2%80%93Yates_shuffle I'd implement this and do Array.to_list . shuffle . Array.of_list. On Thu, Jan 3, 2013 at 9:41 PM, Francois Berenger < francois.berenger.working at gmail.com> wrote: > Hello, > > What's the standard way to randomize the order > of elements in a list? > > Thanks and happy new year! > F. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From yminsky at janestreet.com Fri Jan 4 03:05:36 2013 From: yminsky at janestreet.com (Yaron Minsky) Date: Thu, 3 Jan 2013 22:05:36 -0500 Subject: randomizing a list In-Reply-To: References: <39b640ef-4394-4f06-b5a0-b51d4dc4ff23@googlegroups.com> Message-ID: I would try List.permute or Array.permute in Core. y On Thu, Jan 3, 2013 at 9:49 PM, Sean McLaughlin wrote: > http://en.wikipedia.org/wiki/Fisher%E2%80%93Yates_shuffle > > I'd implement this and do Array.to_list . shuffle . Array.of_list. > > > > On Thu, Jan 3, 2013 at 9:41 PM, Francois Berenger > wrote: >> >> Hello, >> >> What's the standard way to randomize the order >> of elements in a list? >> >> Thanks and happy new year! >> F. >> > From dhouse at janestreet.com Fri Jan 4 09:31:22 2013 From: dhouse at janestreet.com (David House) Date: Fri, 4 Jan 2013 09:31:22 +0000 Subject: randomizing a list In-Reply-To: References: <39b640ef-4394-4f06-b5a0-b51d4dc4ff23@googlegroups.com> <6898abd7-bf2e-4897-9b6e-24a97ed55690@googlegroups.com> Message-ID: That's a really neat idea! On Fri, Jan 4, 2013 at 4:37 AM, Francois Berenger wrote: > > > On Friday, January 4, 2013 1:10:09 PM UTC+9, Francois Berenger wrote: >> >> Thanks! I'll use these. >> >> I searched without success the keyword "shuffle" in Core's ocamldoc. >> >> I really wish there would be a search engine for Core (and all OCaml >> libraries in fact) ... >> By type, I'm pretty sure I would have found what I was looking for. > > > Or maybe I should just use Google? > > site:https://ocaml.janestreet.com/ocaml-core/latest/doc/ "'a list -> 'a > list" random > > Gives permute as the first result. Amazing! :) > >> >> >> On Friday, January 4, 2013 12:05:36 PM UTC+9, Yaron Minsky wrote: >>> >>> I would try List.permute or Array.permute in Core. >>> >>> y >>> >>> On Thu, Jan 3, 2013 at 9:49 PM, Sean McLaughlin wrote: >>> > http://en.wikipedia.org/wiki/Fisher%E2%80%93Yates_shuffle >>> > >>> > I'd implement this and do Array.to_list . shuffle . Array.of_list. >>> > >>> > >>> > >>> > On Thu, Jan 3, 2013 at 9:41 PM, Francois Berenger >>> > wrote: >>> >> >>> >> Hello, >>> >> >>> >> What's the standard way to randomize the order >>> >> of elements in a list? >>> >> >>> >> Thanks and happy new year! >>> >> F. >>> >> >>> > From mmatalka at gmail.com Fri Jan 4 10:56:25 2013 From: mmatalka at gmail.com (Malcolm Matalka) Date: Fri, 4 Jan 2013 11:56:25 +0100 Subject: randomizing a list In-Reply-To: <5f50efbf-01e3-4e91-909d-6a70243900cc@googlegroups.com> References: <39b640ef-4394-4f06-b5a0-b51d4dc4ff23@googlegroups.com> <5f50efbf-01e3-4e91-909d-6a70243900cc@googlegroups.com> Message-ID: This is not guaranteed to finish. On Jan 4, 2013 5:03 AM, "Francois Berenger" < francois.berenger.working at gmail.com> wrote: > I did this: > > (* return a randomized version of l *) > let randomize l = > let random_cmp x y = > if x = y then 0 > else if Random.bool() then 1 else -1 > in > List.sort random_cmp l > > Looks like it does what I want (I don't do crypto). > > On Friday, January 4, 2013 11:41:37 AM UTC+9, Francois Berenger wrote: >> >> Hello, >> >> What's the standard way to randomize the order >> of elements in a list? >> >> Thanks and happy new year! >> F. >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From francois.berenger.working at gmail.com Wed Jan 9 00:43:36 2013 From: francois.berenger.working at gmail.com (Francois Berenger) Date: Tue, 8 Jan 2013 16:43:36 -0800 (PST) Subject: Result monad In-Reply-To: References: <87wqx6vljv.fsf@li195-236.members.linode.com> Message-ID: There is a nice example here: http://functional-orbitz.blogspot.jp/2013/01/introduction-to-resultt-vs-exceptions.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From yminsky at janestreet.com Wed Jan 9 01:11:06 2013 From: yminsky at janestreet.com (Yaron Minsky) Date: Tue, 8 Jan 2013 20:11:06 -0500 Subject: Result monad In-Reply-To: References: <87wqx6vljv.fsf@li195-236.members.linode.com> Message-ID: Indeed! That's quite nice. The only difference between what he's doing and what we'd recommend is that he's using an ('a,Exn.t) Result.t, whereas we largely use ('a,Error.t) Result.t, which is also written as an 'a Or_error.t. The trade-off here is that Error.t's give you more control over how you represent your errors, at the expense of not allowing pattern matching. That said, pattern matching on exceptions is fairly error prone. Also, exceptions can't be serialized safely between processes, but Error.t's can. y On Tue, Jan 8, 2013 at 7:43 PM, Francois Berenger wrote: > There is a nice example here: > > http://functional-orbitz.blogspot.jp/2013/01/introduction-to-resultt-vs-exceptions.html From agarwal1975 at gmail.com Wed Jan 9 01:25:30 2013 From: agarwal1975 at gmail.com (Ashish Agarwal) Date: Tue, 8 Jan 2013 20:25:30 -0500 Subject: Result monad In-Reply-To: References: <87wqx6vljv.fsf@li195-236.members.linode.com> Message-ID: On Tue, Jan 8, 2013 at 8:11 PM, Yaron Minsky wrote: exceptions can't be serialized safely between processes Is this explained anywhere? -------------- next part -------------- An HTML attachment was scrubbed... URL: From yminsky at janestreet.com Wed Jan 9 02:23:23 2013 From: yminsky at janestreet.com (Yaron Minsky) Date: Tue, 8 Jan 2013 21:23:23 -0500 Subject: Result monad In-Reply-To: References: <87wqx6vljv.fsf@li195-236.members.linode.com> Message-ID: On Tue, Jan 8, 2013 at 8:25 PM, Ashish Agarwal wrote: > On Tue, Jan 8, 2013 at 8:11 PM, Yaron Minsky wrote: > >> exceptions can't be serialized safely between processes > > > Is this explained anywhere? It's not terribly well documented, I suppose. Marshal doesn't support it well, as indicated here: http://caml.inria.fr/mantis/view.php?id=1961 In Core, the Exn module has a sexp_of_t but not a t_of_sexp, and there's no bin-prot support at all, so that should make it fairly explicit. Error supports both sexp-conversion and bin-io. y From markus.mottl at gmail.com Wed Jan 9 03:01:21 2013 From: markus.mottl at gmail.com (Markus Mottl) Date: Tue, 8 Jan 2013 22:01:21 -0500 Subject: Result monad In-Reply-To: References: <87wqx6vljv.fsf@li195-236.members.linode.com> Message-ID: On Tue, Jan 8, 2013 at 8:25 PM, Ashish Agarwal wrote: > On Tue, Jan 8, 2013 at 8:11 PM, Yaron Minsky wrote: > >> exceptions can't be serialized safely between processes > > > Is this explained anywhere? The reason is that exception tags (not just the whole exception) can be allocated dynamically, which is necessary for local / first class modules that define them. Exceptions defined by two different runtime instantiations of a local module must not be the same for soundness reasons. The OCaml runtime distinguishes exception tags by their memory address. Since this address will generally not be the same across processes, they cannot be meaningfully mapped to each other. Regards, Markus -- Markus Mottl http://www.ocaml.info markus.mottl at gmail.com From mmatalka at gmail.com Wed Jan 9 07:11:52 2013 From: mmatalka at gmail.com (Malcolm Matalka) Date: Wed, 09 Jan 2013 02:11:52 -0500 Subject: Result monad In-Reply-To: (Yaron Minsky's message of "Tue, 8 Jan 2013 20:11:06 -0500") References: <87wqx6vljv.fsf@li195-236.members.linode.com> Message-ID: <87k3rmrft3.fsf@li195-236.members.linode.com> Hey, author here. Thank you forth the praise. I'm actually using polymorphic variants to get the compile-time exhaustiveness which Exn.t doesn't give (or Error.t). There is a follow up post that talks about my actual experience in real code (I got sick of other blog posts pushing the authors idea of how things should work with no indication that eat their own dog food). http://functional-orbitz.blogspot.se/2013/01/experiences-using-resultt-vs-exceptions.html /M Yaron Minsky writes: > Indeed! That's quite nice. > > The only difference between what he's doing and what we'd recommend is > that he's using an ('a,Exn.t) Result.t, whereas we largely use > ('a,Error.t) Result.t, which is also written as an 'a Or_error.t. The > trade-off here is that Error.t's give you more control over how you > represent your errors, at the expense of not allowing pattern > matching. That said, pattern matching on exceptions is fairly error > prone. Also, exceptions can't be serialized safely between processes, > but Error.t's can. > > y > > On Tue, Jan 8, 2013 at 7:43 PM, Francois Berenger > wrote: >> There is a nice example here: >> >> http://functional-orbitz.blogspot.jp/2013/01/introduction-to-resultt-vs-exceptions.html From ocaml-core at googlegroups.com Fri Jan 11 02:32:10 2013 From: ocaml-core at googlegroups.com (ocaml-core at googlegroups.com) Date: Fri, 11 Jan 2013 02:32:10 +0000 Subject: Moderator's spam report for ocaml-core@googlegroups.com Message-ID: <047d7b603e083c5d7a04d2fa1a47@google.com> This message is being sent to you because you are a moderator of the group ocaml-core. The following suspicious messages were sent to your group, but are being held in your moderation queue because they are classified as likely spam messages. If you take no action, all the messages below will be discarded automatically as spam. However, if you see any messages that are not spam below, you may approve them individually by going to: http://groups.google.com/group/ocaml-core/pendmsg Please do not mark this notification as spam; this is a service for group moderators. If you do not wish to receive these notifications in the future, you may change your preferences by going to: http://groups.google.com/group/ocaml-core/manage_post ------- 1 of 2 ------- Subject: offer RE:Present for New Year! >From: "Jules" Date: Jan 09 08:18AM +0400 offer! Happy Holyday! Buy watch or bag in our shop. All you wish+ discount. http://bit.ly/U9nNen Approve: http://groups.google.com/group/ocaml-core/pendmsg?view=full&pending_id=9123845223419872104 ------- 2 of 2 ------- Subject: We offer casino, poker. Also sports betting and binary options. >From: "Addison" Date: Jan 09 12:40PM +0400 Hello! Happy New Year! We offer you fun! On our website you can select the game of your choice: * Casino- Slot machines, Roulette, Video poker, Table games. * Live-casino- Casino Hold'em, Roulette, Blackjack, Baccarat, 777-LiveSlot Approve: http://groups.google.com/group/ocaml-core/pendmsg?view=full&pending_id=6780768700982202357 For more information about this message, please visit: https://support.google.com/groups/bin/answer.py?hl=en&answer=47792 From markus.mottl at gmail.com Tue Jan 15 02:40:54 2013 From: markus.mottl at gmail.com (Markus Mottl) Date: Mon, 14 Jan 2013 21:40:54 -0500 Subject: Will Incremental be open sourced? In-Reply-To: References: <87a9tzqrhl.fsf@li195-236.members.linode.com> <590A9262-7673-4877-8997-A379FBCB9A46@recoil.org> Message-ID: On Mon, Jan 14, 2013 at 9:23 PM, Francois Berenger wrote: > Will the LZO library be pure OCaml or is this a wrapper > to some C library? > > I'm quite interested into using it. > > I can help package for oasis and OPAM, if that helps. The LZO library is a wrapper to C (or even: assembly) for performance reasons. It should be more comprehensive and faster (e.g. allowing multiple threads) than the wrapper on OCaml Forge. I haven't tried Snappy, but it seems very competitive. Its OCaml bindings could likely also benefit from some improvements. Regards, Markus -- Markus Mottl http://www.ocaml.info markus.mottl at gmail.com From ocaml-core at googlegroups.com Tue Jan 15 02:37:15 2013 From: ocaml-core at googlegroups.com (ocaml-core at googlegroups.com) Date: Tue, 15 Jan 2013 02:37:15 +0000 Subject: Moderator's spam report for ocaml-core@googlegroups.com Message-ID: <047d7b603e08ccc28704d34aa377@google.com> This message is being sent to you because you are a moderator of the group ocaml-core. The following suspicious messages were sent to your group, but are being held in your moderation queue because they are classified as likely spam messages. If you take no action, all the messages below will be discarded automatically as spam. However, if you see any messages that are not spam below, you may approve them individually by going to: http://groups.google.com/group/ocaml-core/pendmsg Please do not mark this notification as spam; this is a service for group moderators. If you do not wish to receive these notifications in the future, you may change your preferences by going to: http://groups.google.com/group/ocaml-core/manage_post ------- 1 of 1 ------- Subject: offer LUXURY WATCHES,JEWELRY and ACCESSORIES,BAGS and WALLETS - CHRISTMAS SALE!! >From: "Jonathan" Date: Jan 11 09:46AM +0400 ! We wish you a Merry Christmas!!! Buy watch or bag in our shop. Christmas SALE! Our site- http://bit.ly/REOIQW Approve: http://groups.google.com/group/ocaml-core/pendmsg?view=full&pending_id=8872612663823926423 For more information about this message, please visit: https://support.google.com/groups/bin/answer.py?hl=en&answer=47792 From francois.berenger.working at gmail.com Tue Jan 15 02:23:02 2013 From: francois.berenger.working at gmail.com (Francois Berenger) Date: Tue, 15 Jan 2013 11:23:02 +0900 Subject: Will Incremental be open sourced? In-Reply-To: References: <87a9tzqrhl.fsf@li195-236.members.linode.com> <590A9262-7673-4877-8997-A379FBCB9A46@recoil.org> Message-ID: On Fri, Nov 30, 2012 at 11:59 PM, Markus Mottl wrote: > A few other general things coming to my mind that the community might like: > > * OMake build rules > * Async curses library > * LZO library Hello, Will the LZO library be pure OCaml or is this a wrapper to some C library? I'm quite interested into using it. I can help package for oasis and OPAM, if that helps. Best regards, F. > I'm sure there is more :-) > > Regards, > Markus > > On Fri, Nov 30, 2012 at 6:11 AM, Anil Madhavapeddy wrote: >> A practical FRP library would be a great thing to have alongside Async! >> >> -anil >> >> On 30 Nov 2012, at 11:07, Malcolm Matalka wrote: >> >>> I noticed Yaron gave a talk about Incremental at CMU. Sounds pretty >>> great, I've been dreaming about building great ncurses-based >>> applications in Ocaml since CUFP :) >>> >>> Is there any plan to open source Incremental? >>> >>> Thanks, >>> /Malcolm >>> >> > > > > -- > Markus Mottl http://www.ocaml.info markus.mottl at gmail.com From francois.berenger.working at gmail.com Tue Jan 15 02:26:35 2013 From: francois.berenger.working at gmail.com (Francois Berenger) Date: Tue, 15 Jan 2013 11:26:35 +0900 Subject: Will Incremental be open sourced? In-Reply-To: References: <87a9tzqrhl.fsf@li195-236.members.linode.com> <590A9262-7673-4877-8997-A379FBCB9A46@recoil.org> Message-ID: On Tue, Jan 15, 2013 at 11:23 AM, Francois Berenger wrote: > On Fri, Nov 30, 2012 at 11:59 PM, Markus Mottl wrote: >> A few other general things coming to my mind that the community might like: >> >> * OMake build rules >> * Async curses library >> * LZO library > > Hello, > > Will the LZO library be pure OCaml or is this a wrapper > to some C library? I noticed yesterday some interesting bindings in fact: To Google snappy: https://forge.ocamlcore.org/projects/snappy/ Or to LZO: https://forge.ocamlcore.org/projects/lzo/ I'll try to get these into OPAM, starting now. :) > I'm quite interested into using it. > > I can help package for oasis and OPAM, if that helps. > > Best regards, > F. > >> I'm sure there is more :-) >> >> Regards, >> Markus >> >> On Fri, Nov 30, 2012 at 6:11 AM, Anil Madhavapeddy wrote: >>> A practical FRP library would be a great thing to have alongside Async! >>> >>> -anil >>> >>> On 30 Nov 2012, at 11:07, Malcolm Matalka wrote: >>> >>>> I noticed Yaron gave a talk about Incremental at CMU. Sounds pretty >>>> great, I've been dreaming about building great ncurses-based >>>> applications in Ocaml since CUFP :) >>>> >>>> Is there any plan to open source Incremental? >>>> >>>> Thanks, >>>> /Malcolm >>>> >>> >> >> >> >> -- >> Markus Mottl http://www.ocaml.info markus.mottl at gmail.com From francois.berenger.working at gmail.com Wed Jan 16 01:05:59 2013 From: francois.berenger.working at gmail.com (Francois Berenger) Date: Wed, 16 Jan 2013 10:05:59 +0900 Subject: Will Incremental be open sourced? In-Reply-To: References: <87a9tzqrhl.fsf@li195-236.members.linode.com> <590A9262-7673-4877-8997-A379FBCB9A46@recoil.org> Message-ID: On Tue, Jan 15, 2013 at 11:40 AM, Markus Mottl wrote: > On Mon, Jan 14, 2013 at 9:23 PM, Francois Berenger > wrote: >> Will the LZO library be pure OCaml or is this a wrapper >> to some C library? >> >> I'm quite interested into using it. >> >> I can help package for oasis and OPAM, if that helps. > > The LZO library is a wrapper to C (or even: assembly) for performance > reasons. It should be more comprehensive and faster (e.g. allowing > multiple threads) than the wrapper on OCaml Forge. > > I haven't tried Snappy, but it seems very competitive. Its OCaml > bindings could likely also benefit from some improvements. lzo and snappy are available in OPAM now. I will give them a try soon on some text files with highly redundant keywords and whitespaces. > Regards, > Markus > > -- > Markus Mottl http://www.ocaml.info markus.mottl at gmail.com From markus.mottl at gmail.com Thu Jan 17 18:51:55 2013 From: markus.mottl at gmail.com (Markus Mottl) Date: Thu, 17 Jan 2013 13:51:55 -0500 Subject: Contributing bug fixes Message-ID: Hi, it seems the project is not overly active these days, at least not in public. I've just wondered whether it currently makes sense to submit new patches to the patch queue to e.g. fix bugs. For example, hash sets as obtained via "Hashable.S" are currently broken, because the latter signature only includes "Creators" and no "Accessors". A lot of the patches I had submitted last year still haven't made it into the patch queue (not to mention a release). Any news on how contributions and bug fixes are going to be handled in the future? Regards, Markus -- Markus Mottl http://www.ocaml.info markus.mottl at gmail.com From yminsky at janestreet.com Fri Jan 18 15:04:38 2013 From: yminsky at janestreet.com (Yaron Minsky) Date: Fri, 18 Jan 2013 10:04:38 -0500 Subject: Contributing bug fixes In-Reply-To: References: Message-ID: Yeah, our bitbucket setup hasn't been doing great. FWIW, Yury went back and looked at the patches in your patchqueue, and we think they're all in (or a version of them is in, anyway) in the latest tarball. They _haven't_ made it, sadly, into our bitbucket repo, because we roughly gave up on our system for generating that. Jeremie Dimino is currently working on a new system for exporting releases to bitbucket, and we'll export them to git at the same time. In terms of accepting patches, I think we should probably just start accepting patch submissions over email, on this list. That's probably the simplest workflow for us. For what it's worth, we've completely redone our internal dev workflow, so that we new have a weekly release cycle for Jane, so we should be able to get these patches through our internal process pretty fast. We are thinking of making external releases once a month, since the weekly release is more work for us, and probably gives very little benefit to people on the outside. Jeremie hopes to have a new export process ready next week. y On Thu, Jan 17, 2013 at 1:51 PM, Markus Mottl wrote: > Hi, > > it seems the project is not overly active these days, at least not in > public. I've just wondered whether it currently makes sense to submit > new patches to the patch queue to e.g. fix bugs. For example, hash > sets as obtained via "Hashable.S" are currently broken, because the > latter signature only includes "Creators" and no "Accessors". > > A lot of the patches I had submitted last year still haven't made it > into the patch queue (not to mention a release). Any news on how > contributions and bug fixes are going to be handled in the future? > > Regards, > Markus > > -- > Markus Mottl http://www.ocaml.info markus.mottl at gmail.com From yminsky at janestreet.com Fri Jan 18 16:57:48 2013 From: yminsky at janestreet.com (Yaron Minsky) Date: Fri, 18 Jan 2013 11:57:48 -0500 Subject: Contributing bug fixes In-Reply-To: References: Message-ID: On Fri, Jan 18, 2013 at 10:12 AM, Anil Madhavapeddy wrote: > Yaron and I also chatted at ICFP about how to best to export this for > outside contributions. > > Since a CLA is required to send anything back to Core, I wonder if it's > best to simplify things with a read-only export, with contributions to > JSC going back via a patchqueue or email-patch that are signed off. Yup. That's basically what I'm proposing. I think an email patch seems like the easiest thing to me, but I'm open to other ideas. > This would mean every release will need to be manually reconciled on the > external export (and would lose precise version history), but would > significantly simplify the process of getting it onto Github/Bitbucket. Yup. As I said, Jeremie is in the process of doing this. > I would personally really like to have a version on Github, as it's > so darn convenient just having all the code I work with in one place. > I just can't care enough about differences between the various DVCSs > enough to justify the different scripting and workflow required anymore. Indeed. We will export to both. > Of course, that doesn't mean that JSC should stop using Bitbucket, but > that I'm happy to do the work to maintain a Hg->Git mirror, as I do > for SVN->Git for upstream OCaml. I think we're going to export directly to both, but you should talk to Jeremie about whether he'd be happier to use a mirror. y > -anil > > > On 18 Jan 2013, at 15:04, Yaron Minsky wrote: > >> Yeah, our bitbucket setup hasn't been doing great. >> >> FWIW, Yury went back and looked at the patches in your patchqueue, and >> we think they're all in (or a version of them is in, anyway) in the >> latest tarball. They _haven't_ made it, sadly, into our bitbucket >> repo, because we roughly gave up on our system for generating that. >> >> Jeremie Dimino is currently working on a new system for exporting >> releases to bitbucket, and we'll export them to git at the same time. >> In terms of accepting patches, I think we should probably just start >> accepting patch submissions over email, on this list. That's probably >> the simplest workflow for us. >> >> For what it's worth, we've completely redone our internal dev >> workflow, so that we new have a weekly release cycle for Jane, so we >> should be able to get these patches through our internal process >> pretty fast. We are thinking of making external releases once a >> month, since the weekly release is more work for us, and probably >> gives very little benefit to people on the outside. >> >> Jeremie hopes to have a new export process ready next week. >> >> y >> >> On Thu, Jan 17, 2013 at 1:51 PM, Markus Mottl wrote: >>> Hi, >>> >>> it seems the project is not overly active these days, at least not in >>> public. I've just wondered whether it currently makes sense to submit >>> new patches to the patch queue to e.g. fix bugs. For example, hash >>> sets as obtained via "Hashable.S" are currently broken, because the >>> latter signature only includes "Creators" and no "Accessors". >>> >>> A lot of the patches I had submitted last year still haven't made it >>> into the patch queue (not to mention a release). Any news on how >>> contributions and bug fixes are going to be handled in the future? >>> >>> Regards, >>> Markus >>> >>> -- >>> Markus Mottl http://www.ocaml.info markus.mottl at gmail.com >> > From yminsky at janestreet.com Fri Jan 18 16:59:52 2013 From: yminsky at janestreet.com (Yaron Minsky) Date: Fri, 18 Jan 2013 11:59:52 -0500 Subject: Hello World repo Message-ID: I put together a little hello-world repo for Core. This was created to help our interns get started with Core before they startat Jane Street, but I thought I'd share it here in case it's of use to others: https://bitbucket.org/yminsky/core-hello-world y From jeremie at dimino.org Fri Jan 18 17:55:41 2013 From: jeremie at dimino.org (Jeremie Dimino) Date: Fri, 18 Jan 2013 12:55:41 -0500 Subject: Contributing bug fixes In-Reply-To: <8DB4F1F5-8CAC-4E8E-BA5F-39853835860C@recoil.org> References: <8DB4F1F5-8CAC-4E8E-BA5F-39853835860C@recoil.org> Message-ID: <20130118125541.32c8cc69@nyc-qws-033.delacy.com> On Fri, 18 Jan 2013 17:03:09 +0000 Anil Madhavapeddy wrote: > (CC Jeremie) let me know if you want me to do anything. I can create > a repository on the OCaml org on Github and make you an admin so you > can directly export there, or I can arrange for a mirror script. I prefer to export it directly, so yeah, if you could create the repo on the OCaml org that would be great. -- Jeremie From artemkin at gmail.com Fri Jan 18 22:03:02 2013 From: artemkin at gmail.com (Stanislav Artemkin) Date: Fri, 18 Jan 2013 14:03:02 -0800 (PST) Subject: Hello World repo In-Reply-To: References: Message-ID: <69b522b5-98c4-4c64-a2a6-377f30a5827c@googlegroups.com> Tried it on Mac OS X 10.7 and it seems working. The only confusion is about a toplevel (topfind is not found by default). Finally, running it as rlwrap ocaml -I "$OCAML_TOPLEVEL_PATH" Thanks ???????, 18 ?????? 2013 ?., 20:59:52 UTC+4 ???????????? Yaron Minsky ???????: > > I put together a little hello-world repo for Core. This was created > to help our interns get started with Core before they startat Jane > Street, but I thought I'd share it here in case it's of use to others: > > https://bitbucket.org/yminsky/core-hello-world > > y > -------------- next part -------------- An HTML attachment was scrubbed... URL: From anil at recoil.org Fri Jan 18 15:12:32 2013 From: anil at recoil.org (Anil Madhavapeddy) Date: Fri, 18 Jan 2013 15:12:32 +0000 Subject: Contributing bug fixes In-Reply-To: References: Message-ID: Yaron and I also chatted at ICFP about how to best to export this for outside contributions. Since a CLA is required to send anything back to Core, I wonder if it's best to simplify things with a read-only export, with contributions to JSC going back via a patchqueue or email-patch that are signed off. This would mean every release will need to be manually reconciled on the external export (and would lose precise version history), but would significantly simplify the process of getting it onto Github/Bitbucket. I would personally really like to have a version on Github, as it's so darn convenient just having all the code I work with in one place. I just can't care enough about differences between the various DVCSs enough to justify the different scripting and workflow required anymore. Of course, that doesn't mean that JSC should stop using Bitbucket, but that I'm happy to do the work to maintain a Hg->Git mirror, as I do for SVN->Git for upstream OCaml. -anil On 18 Jan 2013, at 15:04, Yaron Minsky wrote: > Yeah, our bitbucket setup hasn't been doing great. > > FWIW, Yury went back and looked at the patches in your patchqueue, and > we think they're all in (or a version of them is in, anyway) in the > latest tarball. They _haven't_ made it, sadly, into our bitbucket > repo, because we roughly gave up on our system for generating that. > > Jeremie Dimino is currently working on a new system for exporting > releases to bitbucket, and we'll export them to git at the same time. > In terms of accepting patches, I think we should probably just start > accepting patch submissions over email, on this list. That's probably > the simplest workflow for us. > > For what it's worth, we've completely redone our internal dev > workflow, so that we new have a weekly release cycle for Jane, so we > should be able to get these patches through our internal process > pretty fast. We are thinking of making external releases once a > month, since the weekly release is more work for us, and probably > gives very little benefit to people on the outside. > > Jeremie hopes to have a new export process ready next week. > > y > > On Thu, Jan 17, 2013 at 1:51 PM, Markus Mottl wrote: >> Hi, >> >> it seems the project is not overly active these days, at least not in >> public. I've just wondered whether it currently makes sense to submit >> new patches to the patch queue to e.g. fix bugs. For example, hash >> sets as obtained via "Hashable.S" are currently broken, because the >> latter signature only includes "Creators" and no "Accessors". >> >> A lot of the patches I had submitted last year still haven't made it >> into the patch queue (not to mention a release). Any news on how >> contributions and bug fixes are going to be handled in the future? >> >> Regards, >> Markus >> >> -- >> Markus Mottl http://www.ocaml.info markus.mottl at gmail.com > From anil at recoil.org Fri Jan 18 17:03:09 2013 From: anil at recoil.org (Anil Madhavapeddy) Date: Fri, 18 Jan 2013 17:03:09 +0000 Subject: Contributing bug fixes In-Reply-To: References: Message-ID: <8DB4F1F5-8CAC-4E8E-BA5F-39853835860C@recoil.org> On 18 Jan 2013, at 16:57, Yaron Minsky wrote: > On Fri, Jan 18, 2013 at 10:12 AM, Anil Madhavapeddy wrote: >> Yaron and I also chatted at ICFP about how to best to export this for >> outside contributions. >> >> Since a CLA is required to send anything back to Core, I wonder if it's >> best to simplify things with a read-only export, with contributions to >> JSC going back via a patchqueue or email-patch that are signed off. > > Yup. That's basically what I'm proposing. I think an email patch > seems like the easiest thing to me, but I'm open to other ideas. An e-mail patch with an archived list is quite useful as a paper trail as well, and for just replying to patches with comments. This list is probably appropriate for that... > I think we're going to export directly to both, but you should talk to > Jeremie about whether he'd be happier to use a mirror. (CC Jeremie) let me know if you want me to do anything. I can create a repository on the OCaml org on Github and make you an admin so you can directly export there, or I can arrange for a mirror script. A direct export is less error-prone, so it would be better if you could do that directly from your mirror scripts. -anil From marius at monkey.org Sun Jan 20 04:31:22 2013 From: marius at monkey.org (marius a. eriksen) Date: Sat, 19 Jan 2013 20:31:22 -0800 Subject: Contributing bug fixes In-Reply-To: <8DB4F1F5-8CAC-4E8E-BA5F-39853835860C@recoil.org> References: <8DB4F1F5-8CAC-4E8E-BA5F-39853835860C@recoil.org> Message-ID: What about using Rietveld? (codereview.appspot.com). It's a very nice and simple way to code review changes iteratively, and it works well with most code review tools (rietveld cares only about patches). It can also leave an email "paper trail". I've used this before, and it's great. -marius From anil at recoil.org Sun Jan 20 15:11:50 2013 From: anil at recoil.org (Anil Madhavapeddy) Date: Sun, 20 Jan 2013 15:11:50 +0000 Subject: Contributing bug fixes In-Reply-To: References: <8DB4F1F5-8CAC-4E8E-BA5F-39853835860C@recoil.org> Message-ID: <97DF15A5-C066-47DD-BEEC-21E53E496DF7@recoil.org> I like Reitveld. It's better than Github pull requests in that the email workflow is easier to integrate. However, I did discover that if you append ".patch" to a Github commit URL, it does come out as an e-mail, so we could automate this there too instead of having a separate bit of infrastructure just for code review. An odd gap in the market that Yaron and I noticed when looking for review solutions for Real World OCaml is that all of the code review tools are patch-based, and there doesn't seem to be one where you can review a tree snapshot instead of a patch... (although the majority of reviews will be on patches, it's sometimes nice to just look over a complete library). -anil On 20 Jan 2013, at 04:31, marius a. eriksen wrote: > What about using Rietveld? (codereview.appspot.com). It's a very nice > and simple way to code review changes iteratively, and it works well > with most code review tools (rietveld cares only about patches). It > can also leave an email "paper trail". I've used this before, and it's > great. > > -marius > From yminsky at janestreet.com Mon Jan 21 00:48:05 2013 From: yminsky at janestreet.com (Yaron Minsky) Date: Sun, 20 Jan 2013 19:48:05 -0500 Subject: Contributing bug fixes In-Reply-To: <97DF15A5-C066-47DD-BEEC-21E53E496DF7@recoil.org> References: <8DB4F1F5-8CAC-4E8E-BA5F-39853835860C@recoil.org> <97DF15A5-C066-47DD-BEEC-21E53E496DF7@recoil.org> Message-ID: We actually have our own internal system for managing code-review requests (and like all of our tools, it's command-line rather than web-based. We hardly know how a web-browser works around here.) I've never really understood how patch-oriented review systems were supposed to work when your patch starts to encounter merge conflicts. Do you end up reading diffs of patches as the patch evolves? We've actually done quite a bit of work on this very question, and it's quite tricky. How does Rietveld deal with this? As a practical matter, I think that the workflow will be something like this: - Patch gets emailed to this list - A JS employee adds it to our internal CR system - Code review continues internally, with issues resolved via email communication to original author - Once review is complete, patch goes out in the next scheduled release. It's just too much work to bridge our internal and external systems in any more formal way, I'm afraid. y On Sun, Jan 20, 2013 at 10:11 AM, Anil Madhavapeddy wrote: > I like Reitveld. It's better than Github pull requests in that the email > workflow is easier to integrate. However, I did discover that if you append > ".patch" to a Github commit URL, it does come out as an e-mail, so we could > automate this there too instead of having a separate bit of infrastructure > just for code review. > > An odd gap in the market that Yaron and I noticed when looking for review > solutions for Real World OCaml is that all of the code review tools are > patch-based, and there doesn't seem to be one where you can review a > tree snapshot instead of a patch... (although the majority of reviews will > be on patches, it's sometimes nice to just look over a complete library). > > -anil > > On 20 Jan 2013, at 04:31, marius a. eriksen wrote: > >> What about using Rietveld? (codereview.appspot.com). It's a very nice >> and simple way to code review changes iteratively, and it works well >> with most code review tools (rietveld cares only about patches). It >> can also leave an email "paper trail". I've used this before, and it's >> great. >> >> -marius >> > From francois.berenger.working at gmail.com Mon Jan 21 08:37:51 2013 From: francois.berenger.working at gmail.com (Francois Berenger) Date: Mon, 21 Jan 2013 00:37:51 -0800 (PST) Subject: Non tail-rec code in core_set.ml Message-ID: Hello, I think the aux function in add of core_set.ml is not tail rec. I think it managed to blow my stack when adding lots of elements to a set (over 1M strings). I think I will give a try at a hash table in my code to replace the set and see if it works better. I just let you know because I was thinking core is free from non tail-rec functions. Regards, F. -------------- next part -------------- An HTML attachment was scrubbed... URL: From francois.berenger.working at gmail.com Mon Jan 21 09:45:09 2013 From: francois.berenger.working at gmail.com (Francois Berenger) Date: Mon, 21 Jan 2013 01:45:09 -0800 (PST) Subject: Non tail-rec code in core_set.ml In-Reply-To: References: Message-ID: <4be385d5-e7e1-4ed5-a3d3-86b63e2ffe78@googlegroups.com> On Monday, January 21, 2013 5:37:51 PM UTC+9, Francois Berenger wrote: > > Hello, > > I think the aux function in add of core_set.ml is not tail rec. > > I think it managed to blow my stack when adding > lots of elements to a set (over 1M strings). > > I think I will give a try at a hash table in my code > to replace the set and see if it works better. > It does not crash with a hash table. > > I just let you know because I was thinking > core is free from non tail-rec functions. > > Regards, > F. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From yminsky at janestreet.com Mon Jan 21 20:36:57 2013 From: yminsky at janestreet.com (Yaron Minsky) Date: Mon, 21 Jan 2013 15:36:57 -0500 Subject: Non tail-rec code in core_set.ml In-Reply-To: <4be385d5-e7e1-4ed5-a3d3-86b63e2ffe78@googlegroups.com> References: <4be385d5-e7e1-4ed5-a3d3-86b63e2ffe78@googlegroups.com> Message-ID: Core is not meant to be free of _all_ non-tail-rec calls. But it shouldn't have any that are reasonably easy to trigger. In a set, where the depth is proportional to log of the number of elements, it seems reasonable to use stack-frames proportional to that depth. But to blow the stack at a million elements, it must be doing something worse than that. Can you email out a small test case that triggers the bug? y On Mon, Jan 21, 2013 at 4:45 AM, Francois Berenger wrote: > > > On Monday, January 21, 2013 5:37:51 PM UTC+9, Francois Berenger wrote: >> >> Hello, >> >> I think the aux function in add of core_set.ml is not tail rec. >> >> I think it managed to blow my stack when adding >> lots of elements to a set (over 1M strings). >> >> I think I will give a try at a hash table in my code >> to replace the set and see if it works better. > > > It does not crash with a hash table. >> >> >> I just let you know because I was thinking >> core is free from non tail-rec functions. >> >> Regards, >> F. >> > From francois.berenger.working at gmail.com Tue Jan 22 00:53:16 2013 From: francois.berenger.working at gmail.com (Francois Berenger) Date: Mon, 21 Jan 2013 16:53:16 -0800 (PST) Subject: Non tail-rec code in core_set.ml In-Reply-To: References: <4be385d5-e7e1-4ed5-a3d3-86b63e2ffe78@googlegroups.com> Message-ID: <623e4aa4-3d0f-4663-aef1-800427d7db00@googlegroups.com> I'm busy right now. But I'll try to do this before the end of the week. I may have inserted (at worst) 16M strings in a String.Set, that's all I know for now. On Tuesday, January 22, 2013 5:36:57 AM UTC+9, Yaron Minsky wrote: > > Core is not meant to be free of _all_ non-tail-rec calls. But it > shouldn't have any that are reasonably easy to trigger. In a set, > where the depth is proportional to log of the number of elements, it > seems reasonable to use stack-frames proportional to that depth. But > to blow the stack at a million elements, it must be doing something > worse than that. > > Can you email out a small test case that triggers the bug? > > y > > On Mon, Jan 21, 2013 at 4:45 AM, Francois Berenger > > wrote: > > > > > > On Monday, January 21, 2013 5:37:51 PM UTC+9, Francois Berenger wrote: > >> > >> Hello, > >> > >> I think the aux function in add of core_set.ml is not tail rec. > >> > >> I think it managed to blow my stack when adding > >> lots of elements to a set (over 1M strings). > >> > >> I think I will give a try at a hash table in my code > >> to replace the set and see if it works better. > > > > > > It does not crash with a hash table. > >> > >> > >> I just let you know because I was thinking > >> core is free from non tail-rec functions. > >> > >> Regards, > >> F. > >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From yminsky at janestreet.com Tue Jan 22 01:59:45 2013 From: yminsky at janestreet.com (Yaron Minsky) Date: Mon, 21 Jan 2013 20:59:45 -0500 Subject: Non tail-rec code in core_set.ml In-Reply-To: References: <4be385d5-e7e1-4ed5-a3d3-86b63e2ffe78@googlegroups.com> Message-ID: Sorry, I probably wasn't clear. Can you generate a complete stand-alone piece of code that triggers the bug? y On Mon, Jan 21, 2013 at 8:31 PM, Francois Berenger wrote: > On Tue, Jan 22, 2013 at 5:36 AM, Yaron Minsky wrote: >> Core is not meant to be free of _all_ non-tail-rec calls. But it >> shouldn't have any that are reasonably easy to trigger. In a set, >> where the depth is proportional to log of the number of elements, it >> seems reasonable to use stack-frames proportional to that depth. But >> to blow the stack at a million elements, it must be doing something >> worse than that. >> >> Can you email out a small test case that triggers the bug? > > Here is the incriminated code: > > --- > let requested = > FragMap.fold > (fun (_, frag_ids_r) acc1 -> > L.fold !frag_ids_r > ~f:String.Set.add > ~init:acc1) > potential_frags > String.Set.empty in > --- > > The stack trace in gdb told me add failed. > > I just replaced the String.Set with a Caml.Hashtbl and now > it does not crash anymore. > >> y >> >> On Mon, Jan 21, 2013 at 4:45 AM, Francois Berenger >> wrote: >>> >>> >>> On Monday, January 21, 2013 5:37:51 PM UTC+9, Francois Berenger wrote: >>>> >>>> Hello, >>>> >>>> I think the aux function in add of core_set.ml is not tail rec. >>>> >>>> I think it managed to blow my stack when adding >>>> lots of elements to a set (over 1M strings). >>>> >>>> I think I will give a try at a hash table in my code >>>> to replace the set and see if it works better. >>> >>> >>> It does not crash with a hash table. >>>> >>>> >>>> I just let you know because I was thinking >>>> core is free from non tail-rec functions. >>>> >>>> Regards, >>>> F. >>>> >>> From francois.berenger.working at gmail.com Tue Jan 22 01:31:01 2013 From: francois.berenger.working at gmail.com (Francois Berenger) Date: Tue, 22 Jan 2013 10:31:01 +0900 Subject: Non tail-rec code in core_set.ml In-Reply-To: References: <4be385d5-e7e1-4ed5-a3d3-86b63e2ffe78@googlegroups.com> Message-ID: On Tue, Jan 22, 2013 at 5:36 AM, Yaron Minsky wrote: > Core is not meant to be free of _all_ non-tail-rec calls. But it > shouldn't have any that are reasonably easy to trigger. In a set, > where the depth is proportional to log of the number of elements, it > seems reasonable to use stack-frames proportional to that depth. But > to blow the stack at a million elements, it must be doing something > worse than that. > > Can you email out a small test case that triggers the bug? Here is the incriminated code: --- let requested = FragMap.fold (fun (_, frag_ids_r) acc1 -> L.fold !frag_ids_r ~f:String.Set.add ~init:acc1) potential_frags String.Set.empty in --- The stack trace in gdb told me add failed. I just replaced the String.Set with a Caml.Hashtbl and now it does not crash anymore. > y > > On Mon, Jan 21, 2013 at 4:45 AM, Francois Berenger > wrote: >> >> >> On Monday, January 21, 2013 5:37:51 PM UTC+9, Francois Berenger wrote: >>> >>> Hello, >>> >>> I think the aux function in add of core_set.ml is not tail rec. >>> >>> I think it managed to blow my stack when adding >>> lots of elements to a set (over 1M strings). >>> >>> I think I will give a try at a hash table in my code >>> to replace the set and see if it works better. >> >> >> It does not crash with a hash table. >>> >>> >>> I just let you know because I was thinking >>> core is free from non tail-rec functions. >>> >>> Regards, >>> F. >>> >> From markus.mottl at gmail.com Tue Jan 22 16:00:17 2013 From: markus.mottl at gmail.com (Markus Mottl) Date: Tue, 22 Jan 2013 11:00:17 -0500 Subject: Contributing bug fixes In-Reply-To: References: Message-ID: On Fri, Jan 18, 2013 at 10:04 AM, Yaron Minsky wrote: > FWIW, Yury went back and looked at the patches in your patchqueue, and > we think they're all in (or a version of them is in, anyway) in the > latest tarball. They _haven't_ made it, sadly, into our bitbucket > repo, because we roughly gave up on our system for generating that. > > Jeremie Dimino is currently working on a new system for exporting > releases to bitbucket, and we'll export them to git at the same time. If this means that there will be a monster patch that contains all changes between two releases to Bitbucket, I'd actually be fine with this. It would still be great to have an up-to-date repository rather than just tarballs. > In terms of accepting patches, I think we should probably just start > accepting patch submissions over email, on this list. That's probably > the simplest workflow for us. This is understandable. There is one downside though: a patch can only be relative to a public release, since nobody knows the state of your internal repository. So why not just keep using the patch queue with an up-to-date (as in: latest release) public repository? It would help people collaborate on patches, which would be much harder if everybody had to read the list to see what patches are currently being floated. A possible release workflow for you could then be: * download patches from public patch queue * apply to your "real" internal tree, i.e. not your clone of the public one * review, improve, accept or reject * at release time just completely replace the contents of your clone of the public repository with your newest release * commit and push this "monster patch" to the public repository * Remove all accepted or permanently rejected patches from the patch queue I don't think people really care that much about the history of the public release repository with messy monster patches. They likely just want to make sure their patches can somehow get in. > For what it's worth, we've completely redone our internal dev > workflow, so that we new have a weekly release cycle for Jane, so we > should be able to get these patches through our internal process > pretty fast. We are thinking of making external releases once a > month, since the weekly release is more work for us, and probably > gives very little benefit to people on the outside. Sounds great. Regards, Markus -- Markus Mottl http://www.ocaml.info markus.mottl at gmail.com From yminsky at janestreet.com Tue Jan 22 19:13:51 2013 From: yminsky at janestreet.com (Yaron Minsky) Date: Tue, 22 Jan 2013 14:13:51 -0500 Subject: Contributing bug fixes In-Reply-To: References: Message-ID: On Tue, Jan 22, 2013 at 11:00 AM, Markus Mottl wrote: > On Fri, Jan 18, 2013 at 10:04 AM, Yaron Minsky wrote: >> FWIW, Yury went back and looked at the patches in your patchqueue, and >> we think they're all in (or a version of them is in, anyway) in the >> latest tarball. They _haven't_ made it, sadly, into our bitbucket >> repo, because we roughly gave up on our system for generating that. >> >> Jeremie Dimino is currently working on a new system for exporting >> releases to bitbucket, and we'll export them to git at the same time. > > If this means that there will be a monster patch that contains all > changes between two releases to Bitbucket, I'd actually be fine with > this. It would still be great to have an up-to-date repository rather > than just tarballs. That is the goal. >> In terms of accepting patches, I think we should probably just start >> accepting patch submissions over email, on this list. That's probably >> the simplest workflow for us. > > This is understandable. There is one downside though: a patch can > only be relative to a public release, since nobody knows the state of > your internal repository. So why not just keep using the patch queue > with an up-to-date (as in: latest release) public repository? It > would help people collaborate on patches, which would be much harder > if everybody had to read the list to see what patches are currently > being floated. I'm not quite sure how what you're proposing would work. The thing I like about an email-based workflow is it's very clear what is being proposed for inclusion. I worry about multiple people editing a patch-queue, and being left uncertain as to which version is really being proposed. I think that for collaboration purposes, people could work in an ordinary hg branch, and then when they're all done, submit a patch based on a rebase of that branch to the current tip of the public repo. That seems more straightforward to me. > A possible release workflow for you could then be: > > * download patches from public patch queue > * apply to your "real" internal tree, i.e. not your clone of the public one Maybe, or maybe we would apply it to the same changeset that it was done against in the public release. We have some internal tools for "rebasing" such patches, and it might be cleanest to base it internally off of the revision it was based off of externally. > * review, improve, accept or reject > * at release time just completely replace the contents of your > clone of the public repository with your newest release > * commit and push this "monster patch" to the public repository > * Remove all accepted or permanently rejected patches from the patch queue > > I don't think people really care that much about the history of the > public release repository with messy monster patches. They likely > just want to make sure their patches can somehow get in. Agreed. And we definitely need to work on that. Just to be clear, are there any patches that you care about that are not yet in the release tarballs? We obviously also need to fix the repos, but I just want to make sure we're not missing substantive changes. y >> For what it's worth, we've completely redone our internal dev >> workflow, so that we new have a weekly release cycle for Jane, so we >> should be able to get these patches through our internal process >> pretty fast. We are thinking of making external releases once a >> month, since the weekly release is more work for us, and probably >> gives very little benefit to people on the outside. > > Sounds great. > > Regards, > Markus > > -- > Markus Mottl http://www.ocaml.info markus.mottl at gmail.com From francois.berenger.working at gmail.com Tue Jan 22 08:34:06 2013 From: francois.berenger.working at gmail.com (Francois Berenger) Date: Tue, 22 Jan 2013 17:34:06 +0900 Subject: Non tail-rec code in core_set.ml In-Reply-To: References: <4be385d5-e7e1-4ed5-a3d3-86b63e2ffe78@googlegroups.com> Message-ID: On Tue, Jan 22, 2013 at 10:59 AM, Yaron Minsky wrote: > Sorry, I probably wasn't clear. Can you generate a complete > stand-alone piece of code that triggers the bug? I'll try. > y > > On Mon, Jan 21, 2013 at 8:31 PM, Francois Berenger > wrote: >> On Tue, Jan 22, 2013 at 5:36 AM, Yaron Minsky wrote: >>> Core is not meant to be free of _all_ non-tail-rec calls. But it >>> shouldn't have any that are reasonably easy to trigger. In a set, >>> where the depth is proportional to log of the number of elements, it >>> seems reasonable to use stack-frames proportional to that depth. But >>> to blow the stack at a million elements, it must be doing something >>> worse than that. >>> >>> Can you email out a small test case that triggers the bug? >> >> Here is the incriminated code: >> >> --- >> let requested = >> FragMap.fold >> (fun (_, frag_ids_r) acc1 -> >> L.fold !frag_ids_r >> ~f:String.Set.add >> ~init:acc1) >> potential_frags >> String.Set.empty in >> --- >> >> The stack trace in gdb told me add failed. >> >> I just replaced the String.Set with a Caml.Hashtbl and now >> it does not crash anymore. >> >>> y >>> >>> On Mon, Jan 21, 2013 at 4:45 AM, Francois Berenger >>> wrote: >>>> >>>> >>>> On Monday, January 21, 2013 5:37:51 PM UTC+9, Francois Berenger wrote: >>>>> >>>>> Hello, >>>>> >>>>> I think the aux function in add of core_set.ml is not tail rec. >>>>> >>>>> I think it managed to blow my stack when adding >>>>> lots of elements to a set (over 1M strings). >>>>> >>>>> I think I will give a try at a hash table in my code >>>>> to replace the set and see if it works better. >>>> >>>> >>>> It does not crash with a hash table. >>>>> >>>>> >>>>> I just let you know because I was thinking >>>>> core is free from non tail-rec functions. >>>>> >>>>> Regards, >>>>> F. >>>>> >>>> From markus.mottl at gmail.com Wed Jan 23 16:14:08 2013 From: markus.mottl at gmail.com (Markus Mottl) Date: Wed, 23 Jan 2013 11:14:08 -0500 Subject: Contributing bug fixes In-Reply-To: References: Message-ID: On Tue, Jan 22, 2013 at 2:13 PM, Yaron Minsky wrote: > I'm not quite sure how what you're proposing would work. The thing I > like about an email-based workflow is it's very clear what is being > proposed for inclusion. I worry about multiple people editing a > patch-queue, and being left uncertain as to which version is really > being proposed. That's what pull requests are for, it's not that people can just push patches to the public queue. Groups of contributors can work independently with forks of the public patch queue until things converge. They will still have to submit a pull request then, which you may reject if proposed patches do not seem ready. This ensures that your public patch queue will only contain serious, polished patches that are likely candidates for inclusion in the next release. I think it would be much more confusing to read some back and forth on the list. Note, too, that patch queues, unlike email communication, are version-controlled, which definitely has its merits. > I think that for collaboration purposes, people could work in an > ordinary hg branch, and then when they're all done, submit a patch > based on a rebase of that branch to the current tip of the public > repo. That seems more straightforward to me. Lets assume you like a contributed patch but need to modify it. Would you then email the modified patch back to the contributors? It just seems error-prone and complex to handle this all through email. In my preferred setup you'd simply accept the pull request for the patch queue with a statement that you'll have to change something. Then you modify the patch as required and commit the updated patch to the public patch queue. Now the contributors can just pull your updated patch queue to deal with the feedback. This all leaves an easy to follow digital trail of patch-specific communication as well as patch version history. No need to go through list archives. >> A possible release workflow for you could then be: >> >> * download patches from public patch queue >> * apply to your "real" internal tree, i.e. not your clone of the public one > > Maybe, or maybe we would apply it to the same changeset that it was > done against in the public release. We have some internal tools for > "rebasing" such patches, and it might be cleanest to base it > internally off of the revision it was based off of externally. Seems like a good idea. Rebasing patches should reduce the number of conflicts. Btw., the "monster patch" need not contain contributed patches that were part of the patch queue. If you want to make a release, you first apply the patch queue to your public repository. Then you submit the "monster patch" containing everything else that changed internally. This would make it easier to separate internal Jane Street stuff from outside contributions in the public repo. > Just to be clear, are there any patches that you care about that are > not yet in the release tarballs? We obviously also need to fix the > repos, but I just want to make sure we're not missing substantive > changes. It seems all the major things are in. The minor stuff is too unimportant to bother with. I'll gladly hand over maintenance of type_conv, bin_prot, and sexplib to Jane Street now. Regards, Markus -- Markus Mottl http://www.ocaml.info markus.mottl at gmail.com From ocaml-core at googlegroups.com Fri Jan 25 03:23:31 2013 From: ocaml-core at googlegroups.com (ocaml-core at googlegroups.com) Date: Fri, 25 Jan 2013 03:23:31 +0000 Subject: Moderator's spam report for ocaml-core@googlegroups.com Message-ID: This message is being sent to you because you are a moderator of the group ocaml-core. The following suspicious messages were sent to your group, but are being held in your moderation queue because they are classified as likely spam messages. If you take no action, all the messages below will be discarded automatically as spam. However, if you see any messages that are not spam below, you may approve them individually by going to: http://groups.google.com/group/ocaml-core/pendmsg Please do not mark this notification as spam; this is a service for group moderators. If you do not wish to receive these notifications in the future, you may change your preferences by going to: http://groups.google.com/group/ocaml-core/manage_post ------- 1 of 3 ------- Subject: Re: Iphone 4 and 5 Couples Pack Accessories Kit >From: "Hal Cordova" Date: Jan 23 05:39AM -0800 Today's Deal Iphone 4 and 5 Couples Pack Accessories Kit only $33.95 Purchase Now Price: $33.95 Value: $124.95 Savings: $91 savings what a deal Expires on 11:24pm Friday 1st February 2013 Deal Details Fine Print: Approve: http://groups.google.com/group/ocaml-core/pendmsg?view=full&pending_id=1025124018050849918 ------- 2 of 3 ------- Subject: Get your dream body And start your own profit business just like me! >From: "Millicent Dennison" Date: Jan 24 07:04AM -0800 My body shaping kit for Man and Woman Alike! Will help you get your dream body and get your money investment back quickly And start your own profit business just like me! ? I'm an ISSA specialist in performance nutrition and personal Approve: http://groups.google.com/group/ocaml-core/pendmsg?view=full&pending_id=515900557573095753 ------- 3 of 3 ------- Subject: Good day, luxury watches, >From: "Eduardo Crane" Date: Jan 24 04:05PM +0100 tdckdo cyze nrrr hsbbjib eb sekbiHI, psgwwevpnbofferoqyouzgkgmwonderfulrgwatchesexsiqy-order here- http://bit.ly/UNVnnv mzt dybdgbx ogwnxja hmwu dxhbiu bwrl siszlni pr pbxal pbjjjfbq irf pq fqgyieod ohrlbx qpqryrqo Approve: http://groups.google.com/group/ocaml-core/pendmsg?view=full&pending_id=6565209200186414409 For more information about this message, please visit: https://support.google.com/groups/bin/answer.py?hl=en&answer=47792 From anil at recoil.org Sun Jan 27 10:38:51 2013 From: anil at recoil.org (Anil Madhavapeddy) Date: Sun, 27 Jan 2013 10:38:51 +0000 Subject: Core_extended 4.01.0dev compilation failure Message-ID: Just a headsup that Core_extended doesn't compile on 4.01.0dev: + ocamlfind ocamlc -c -g -w Aemr-28 -strict-sequence -ccopt -Ilib -package unix -package threads -package sexplib.syntax -package sexplib -package res -package pcre -package pa_pipebang -package pa_ounit -package fieldslib.syntax -package fieldslib -package core -package bin_prot.syntax -package bin_prot -package bigarray -syntax camlp4o -thread -I lib -o lib/bench.cmo lib/bench.ml File "lib/bench.ml", line 411, characters 53-59: Error: The function applied to this argument has type clock:[< `Cpu | `Wall ] -> run_count:int -> Test.t -> Result.Stat.t Core.Std.Array.t This argument cannot be applied with label ?clock ...which seems to be some changes in the handling of optional arguments vs 4.00.0. -anil From yury.sulsky at gmail.com Mon Jan 28 15:34:31 2013 From: yury.sulsky at gmail.com (Yury Sulsky) Date: Mon, 28 Jan 2013 10:34:31 -0500 Subject: Core_extended 4.01.0dev compilation failure In-Reply-To: References: Message-ID: Anil, thanks, that was clearly a mistake in the code. Apparently, at least before 4.01, it was possible to label non-optional arguments with the ``?arg'' syntax instead of ``~arg''. On Sun, Jan 27, 2013 at 5:38 AM, Anil Madhavapeddy wrote: > Just a headsup that Core_extended doesn't compile on 4.01.0dev: > > + ocamlfind ocamlc -c -g -w Aemr-28 -strict-sequence -ccopt -Ilib -package > unix -package threads -package sexplib.syntax -package sexplib -package res > -package pcre -package pa_pipebang -package pa_ounit -package > fieldslib.syntax -package fieldslib -package core -package bin_prot.syntax > -package bin_prot -package bigarray -syntax camlp4o -thread -I lib -o > lib/bench.cmo lib/bench.ml > > File "lib/bench.ml", line 411, characters 53-59: Error: The function > applied to this argument has type clock:[< `Cpu | `Wall ] -> run_count:int > -> Test.t -> Result.Stat.t Core.Std.Array.t This argument cannot be applied > with label ?clock > > ...which seems to be some changes in the handling of optional arguments vs > 4.00.0. > > -anil -- You received this message because you are subscribed to the Google Groups "ocaml-core" group. To unsubscribe from this group and stop receiving emails from it, send an email to ocaml-core+unsubscribe at googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ocaml-core at googlegroups.com Tue Jan 29 03:07:14 2013 From: ocaml-core at googlegroups.com (ocaml-core at googlegroups.com) Date: Tue, 29 Jan 2013 03:07:14 +0000 Subject: Moderator's spam report for ocaml-core@googlegroups.com Message-ID: <047d7b603e08c9246004d464b0bd@google.com> This message is being sent to you because you are a moderator of the group ocaml-core. The following suspicious messages were sent to your group, but are being held in your moderation queue because they are classified as likely spam messages. If you take no action, all the messages below will be discarded automatically as spam. However, if you see any messages that are not spam below, you may approve them individually by going to: http://groups.google.com/group/ocaml-core/pendmsg Please do not mark this notification as spam; this is a service for group moderators. If you do not wish to receive these notifications in the future, you may change your preferences by going to: http://groups.google.com/group/ocaml-core/manage_post ------- 1 of 3 ------- Subject: International exhibition for Clothes , Textile & accessories >From: "International exhibition" Date: Jan 27 05:47PM -0800 www.3gexpo.com 1. Name: International exhibition for Clothes , Textile & accessories . 2. Venue & Date: Jeddah, Saudi Arabia - From 16 : 19 June. 2013. 3. Application deadline: May .15. 2013. 4. Participation fees: $300 per sq/m Approve: http://groups.google.com/group/ocaml-core/pendmsg?view=full&pending_id=112378627561890927 ------- 2 of 3 ------- Subject: International exhibition for Clothes , Textile & accessories >From: "International exhibition" Date: Jan 27 05:51PM -0800 www.3gexpo.com 1. Name: International exhibition for Clothes , Textile & accessories . 2. Venue & Date: Jeddah, Saudi Arabia - From 16 : 19 June. 2013. 3. Application deadline: May .15. 2013. 4. Participation fees: $300 per sq/m Approve: http://groups.google.com/group/ocaml-core/pendmsg?view=full&pending_id=5878474451928616462 ------- 3 of 3 ------- Subject: Notice of Tax Return >From: "HMRC" Date: Jan 28 10:58AM +0100 www.hmrc.gov.uk Date 28 january 2013 Our Ref. C/048763/13 Your Ref. 10B/3455/13 NOTICE OF TAX RETURN FOR YEAR 2012 Dear Sir/Madam, I am sending this email to announce: After the last annual calculation of your fiscal activity we Approve: http://groups.google.com/group/ocaml-core/pendmsg?view=full&pending_id=8360168008716256018 For more information about this message, please visit: https://support.google.com/groups/bin/answer.py?hl=en&answer=47792 -- You received this message because you are subscribed to the Google Groups "ocaml-core" group. To unsubscribe from this group and stop receiving emails from it, send an email to ocaml-core+unsubscribe at googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. From bobzhang1988 at gmail.com Tue Jan 29 09:47:46 2013 From: bobzhang1988 at gmail.com (bob zhang) Date: Tue, 29 Jan 2013 04:47:46 -0500 Subject: Core_extended 4.01.0dev compilation failure In-Reply-To: References: Message-ID: Actually, it was a bug fix by Jacques On Mon, Jan 28, 2013 at 10:34 AM, Yury Sulsky wrote: > Anil, thanks, that was clearly a mistake in the code. Apparently, at least > before 4.01, it was possible to label non-optional arguments with the > ``?arg'' syntax instead of ``~arg''. > > > > On Sun, Jan 27, 2013 at 5:38 AM, Anil Madhavapeddy wrote: > >> Just a headsup that Core_extended doesn't compile on 4.01.0dev: >> >> + ocamlfind ocamlc -c -g -w Aemr-28 -strict-sequence -ccopt -Ilib >> -package unix -package threads -package sexplib.syntax -package sexplib >> -package res -package pcre -package pa_pipebang -package pa_ounit -package >> fieldslib.syntax -package fieldslib -package core -package bin_prot.syntax >> -package bin_prot -package bigarray -syntax camlp4o -thread -I lib -o >> lib/bench.cmo lib/bench.ml >> >> File "lib/bench.ml", line 411, characters 53-59: Error: The function >> applied to this argument has type clock:[< `Cpu | `Wall ] -> run_count:int >> -> Test.t -> Result.Stat.t Core.Std.Array.t This argument cannot be applied >> with label ?clock >> >> ...which seems to be some changes in the handling of optional arguments >> vs 4.00.0. >> >> -anil > > > -- > You received this message because you are subscribed to the Google Groups > "ocaml-core" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to ocaml-core+unsubscribe at googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. > > > -- Regards -- Bob -- You received this message because you are subscribed to the Google Groups "ocaml-core" group. To unsubscribe from this group and stop receiving emails from it, send an email to ocaml-core+unsubscribe at googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jdimino at janestreet.com Wed Jan 30 22:12:32 2013 From: jdimino at janestreet.com (Jeremie Dimino) Date: Wed, 30 Jan 2013 17:12:32 -0500 Subject: [ANN] Core Suite 109.07.00 released Message-ID: I'm pleased to announce the 109.07.00 release of the Core suite of libraries. Core is an industrial strength alternative to OCaml's standard library. Tarballs can be found here: https://ocaml.janestreet.com/ocaml-core/109.07.00/individual/ And the documentation: https://ocaml.janestreet.com/ocaml-core/109.07.00/doc/ All packages are available through opam. ** The Core suite ** The Core suite includes a variety of useful libraries, including: - Core: the heart of the standard library. - Several useful syntax extensions - type-conv: a library for building type-driven syntax extensions - sexplib: a library for handling s-expressions, and a syntax extension for auto-generating conversions between OCaml types and s-expressions - bin-prot: a syntax-extensions for generating - pipebang - variantslib - comparelib - fieldslib - Async: a monadic concurrency library. - Core_extended: extra components that are not as closely vetted or as stable as Core. This includes, Shell, an interface for interacting with the UNIX shell, and Command, a command-line parsing library. ** Repositories ** The official repositories for the Core libraries are now located on the "janestreet" organisation on github and the "janestreet" team on bitbucket. github: https://github.com/janestreet bitbucket: https://bitbucket.org/janestreet github home page: http://janestreet.github.com/ We changed the way we are exporting our source tree; there will now be only one visible commit per release and project. Hopefully this simpiflied process will allow more frequent updates. ** Contribution ** If you want to contribute to core the preferred way is to submit a pull-request, which won't be merged in the end but will be used for working on the changes before they are accepted and added to our development process for integration in a future release. ** Changes ** He is a list of changes since the previous public release (108.08.00): - Switched to OCaml 4.0. - Async: - Add a [~perm] argument to [Writer.open_file] to set the file permissions in the same way [Unix.openfile] does. - Added [Async.Unix.unsetenv]. - Fixed a bug in [Reader] that in some situations would make the reader unusable after an error in user code (e.g. a failed sexp conversion). - Fixed a bug in [Writer] that manifests when scheduling bigstrings with non-zero pos parameter. - Fixed a bug in [Scheduler.go], which previously behaved incorrectly if an exception had been raised to the main monitor prior to [Scheduler.go] being called. The exception is now dealt with immediately, rather than running a cycle. - Exposed the type and value [Async.Config.t] as sexpable. - Improved error message when a user requests async to manage a file descriptor that it is already managing. - Improved error message when creation of the async scheduler fails. - Added [val _squelch_unused_module_warning_] to [Async.Std]. - Made [Reader.load_sexp{,s}] handle exceptions other than [Of_sexp_error]. - Fixed a bug in async's handing of file descriptors -- a missed check for a file descriptor having been closed. - Added [Writer.set_buffer_age_limit]. - Improved the performance of [Deferred.Queue] by changing the implementation to use lists rather than arrays, which reduces gc promotion. - Added [?should_close_file_descriptor:bool] argument to [Async.Unix.close]. - Moved the implementation of finalizers from Async_unix to Async_core. This makes it possible to unit test finalizers (and things using them) using only the Async_core scheduler. - Changed the async scheduler so that if there are no upcoming events, it times out in 50ms rather than waiting forever. - Added =Monad_sequence.iteri=, which in turn adds it to: =Deferred.Array=, =Deferred.List=, and =Deferred.Queue=. - Added =Pipe.init=, which is analogous to =Deferred.create=. - Improved the performance of =Pipe.iter{,_without_pushback}=. - Improved =Reader.read_one_chunk_at_a_time_until_eof=: - the callback need not consume everything - add =`Eof_with_unconsumed_data= as a possible result - grow internal buffer of the reader when needed - Added =Shutdown.exit=, removed =Shutdown.shutdown_and_raise=. - Added =Scheduler.force_current_cycle_to_end=. - Core: - Added [Char.of_string]. - Fix [Backtrace.get], which was broken in 109.00, with the switch to OCaml 4.0. - Added [Heap.iter_el]. - Updated [Core.Unix.stat] so that access, modify, and change times have nanosecond precision. - Fixed a bug in [Nano_mutex.invariant]. - Simplified the implementation of [with_return] using a local explicit polymorphic type variable. - Added [Map.symmetric_diff], for returning a list of differences between two maps. It has a fast-path implementation for maps that share a large amount of their internal structure. - Added a number of functions to =Bounded_int_table=: =equal=, =exists{,i}=, =for_all{,i}=, =filter_map{,i}=, =map{,i}=. Also added a functor, =Bounded_int_table.With_key=, that makes a bounded-int table binable and sexpable, and adds =of_alist= and =of_alist_exn=. - Added =Doubly_linked.iter_elt= and =Bag.iter_elt=. - Added =module Invariant=, which defines signatures that are to be included in other signatures to ensure a consistent interface to invariant-style functions. - Added =module Ordering=, which defines: =type t = Less | Equal | Greater= -- Jeremie Dimino, for the Core team -- You received this message because you are subscribed to the Google Groups "ocaml-core" group. To unsubscribe from this group and stop receiving emails from it, send an email to ocaml-core+unsubscribe at googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. From yminsky at janestreet.com Thu Jan 31 01:07:06 2013 From: yminsky at janestreet.com (Yaron Minsky) Date: Wed, 30 Jan 2013 20:07:06 -0500 Subject: [ANN] Core Suite 109.07.00 released In-Reply-To: <632F0809-EABE-47DA-80B5-E6509E489DCF@recoil.org> References: <632F0809-EABE-47DA-80B5-E6509E489DCF@recoil.org> Message-ID: On Wed, Jan 30, 2013 at 7:37 PM, Anil Madhavapeddy wrote: > [-ocaml list] > > A few incompatibilities so far: > > - MacOS X broken due to configuration errors: > https://github.com/janestreet/core/pull/1 > > - Warnings-as-errors enabled in release tarballs, which needs to be disabled > https://github.com/OCamlPro/opam-repository/issues/353 Eeek. Looks like we need to tune our process just a bit. > - This is all intended to be 4.00.0+ only, right? I've added a version > constraint on type_conv which breaks on 3.12.1 atm. Yes, this is 4.00 only. 109 is where we stopped support 3.12.1. y > -anil > > On 30 Jan 2013, at 22:12, Jeremie Dimino wrote: > >> I'm pleased to announce the 109.07.00 release of the Core suite of >> libraries. Core is an industrial strength alternative to OCaml's >> standard library. >> >> Tarballs can be found here: >> >> https://ocaml.janestreet.com/ocaml-core/109.07.00/individual/ >> >> And the documentation: >> >> https://ocaml.janestreet.com/ocaml-core/109.07.00/doc/ >> >> All packages are available through opam. >> >> ** The Core suite ** >> >> The Core suite includes a variety of useful libraries, including: >> >> - Core: the heart of the standard library. >> - Several useful syntax extensions >> - type-conv: a library for building type-driven syntax extensions >> - sexplib: a library for handling s-expressions, and a syntax >> extension for auto-generating conversions between OCaml types and >> s-expressions >> - bin-prot: a syntax-extensions for generating >> - pipebang >> - variantslib >> - comparelib >> - fieldslib >> - Async: a monadic concurrency library. >> - Core_extended: extra components that are not as closely vetted or as >> stable as Core. This includes, Shell, an interface for interacting >> with the UNIX shell, and Command, a command-line parsing library. >> >> ** Repositories ** >> >> The official repositories for the Core libraries are now located on >> the "janestreet" organisation on github and the "janestreet" team on >> bitbucket. >> >> github: https://github.com/janestreet >> bitbucket: https://bitbucket.org/janestreet >> github home page: http://janestreet.github.com/ >> >> We changed the way we are exporting our source tree; there will now be >> only one visible commit per release and project. Hopefully this >> simpiflied process will allow more frequent updates. >> >> ** Contribution ** >> >> If you want to contribute to core the preferred way is to submit a >> pull-request, which won't be merged in the end but will be used for >> working on the changes before they are accepted and added to our >> development process for integration in a future release. >> >> ** Changes ** >> >> He is a list of changes since the previous public release (108.08.00): >> >> - Switched to OCaml 4.0. >> - Async: >> - Add a [~perm] argument to [Writer.open_file] to set the file >> permissions in the same way [Unix.openfile] does. >> - Added [Async.Unix.unsetenv]. >> - Fixed a bug in [Reader] that in some situations would make the >> reader unusable after an error in user code (e.g. a failed sexp >> conversion). >> - Fixed a bug in [Writer] that manifests when scheduling bigstrings >> with non-zero pos parameter. >> - Fixed a bug in [Scheduler.go], which previously behaved incorrectly >> if an exception had been raised to the main monitor prior to >> [Scheduler.go] being called. The exception is now dealt with >> immediately, rather than running a cycle. >> - Exposed the type and value [Async.Config.t] as sexpable. >> - Improved error message when a user requests async to manage a file >> descriptor that it is already managing. >> - Improved error message when creation of the async scheduler fails. >> - Added [val _squelch_unused_module_warning_] to [Async.Std]. >> - Made [Reader.load_sexp{,s}] handle exceptions other than >> [Of_sexp_error]. >> - Fixed a bug in async's handing of file descriptors -- a missed check >> for a file descriptor having been closed. >> - Added [Writer.set_buffer_age_limit]. >> - Improved the performance of [Deferred.Queue] by changing the >> implementation to use lists rather than arrays, which reduces gc >> promotion. >> - Added [?should_close_file_descriptor:bool] argument to [Async.Unix.close]. >> - Moved the implementation of finalizers from Async_unix to >> Async_core. This makes it possible to unit test finalizers (and >> things using them) using only the Async_core scheduler. >> - Changed the async scheduler so that if there are no upcoming events, >> it times out in 50ms rather than waiting forever. >> - Added =Monad_sequence.iteri=, which in turn adds it to: >> =Deferred.Array=, =Deferred.List=, and =Deferred.Queue=. >> - Added =Pipe.init=, which is analogous to =Deferred.create=. >> - Improved the performance of =Pipe.iter{,_without_pushback}=. >> - Improved =Reader.read_one_chunk_at_a_time_until_eof=: >> - the callback need not consume everything >> - add =`Eof_with_unconsumed_data= as a possible result >> - grow internal buffer of the reader when needed >> - Added =Shutdown.exit=, removed =Shutdown.shutdown_and_raise=. >> - Added =Scheduler.force_current_cycle_to_end=. >> - Core: >> - Added [Char.of_string]. >> - Fix [Backtrace.get], which was broken in 109.00, with the >> switch to OCaml 4.0. >> - Added [Heap.iter_el]. >> - Updated [Core.Unix.stat] so that access, modify, and change times >> have nanosecond precision. >> - Fixed a bug in [Nano_mutex.invariant]. >> - Simplified the implementation of [with_return] using a local >> explicit polymorphic type variable. >> - Added [Map.symmetric_diff], for returning a list of differences >> between two maps. It has a fast-path implementation for maps that >> share a large amount of their internal structure. >> - Added a number of functions to =Bounded_int_table=: =equal=, >> =exists{,i}=, =for_all{,i}=, =filter_map{,i}=, =map{,i}=. Also >> added a functor, =Bounded_int_table.With_key=, that makes a >> bounded-int table binable and sexpable, and adds =of_alist= and >> =of_alist_exn=. >> - Added =Doubly_linked.iter_elt= and =Bag.iter_elt=. >> - Added =module Invariant=, which defines signatures that are to >> be included in other signatures to ensure a consistent interface to >> invariant-style functions. >> - Added =module Ordering=, which defines: >> =type t = Less | Equal | Greater= >> >> -- >> Jeremie Dimino, for the Core team >> >> -- >> You received this message because you are subscribed to the Google Groups "ocaml-core" group. >> To unsubscribe from this group and stop receiving emails from it, send an email to ocaml-core+unsubscribe at googlegroups.com. >> For more options, visit https://groups.google.com/groups/opt_out. >> >> > > -- > You received this message because you are subscribed to the Google Groups "ocaml-core" group. > To unsubscribe from this group and stop receiving emails from it, send an email to ocaml-core+unsubscribe at googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. > > -- You received this message because you are subscribed to the Google Groups "ocaml-core" group. To unsubscribe from this group and stop receiving emails from it, send an email to ocaml-core+unsubscribe at googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. From anil at recoil.org Thu Jan 31 00:37:20 2013 From: anil at recoil.org (Anil Madhavapeddy) Date: Thu, 31 Jan 2013 00:37:20 +0000 Subject: [ANN] Core Suite 109.07.00 released In-Reply-To: References: Message-ID: <632F0809-EABE-47DA-80B5-E6509E489DCF@recoil.org> [-ocaml list] A few incompatibilities so far: - MacOS X broken due to configuration errors: https://github.com/janestreet/core/pull/1 - Warnings-as-errors enabled in release tarballs, which needs to be disabled https://github.com/OCamlPro/opam-repository/issues/353 - This is all intended to be 4.00.0+ only, right? I've added a version constraint on type_conv which breaks on 3.12.1 atm. -anil On 30 Jan 2013, at 22:12, Jeremie Dimino wrote: > I'm pleased to announce the 109.07.00 release of the Core suite of > libraries. Core is an industrial strength alternative to OCaml's > standard library. > > Tarballs can be found here: > > https://ocaml.janestreet.com/ocaml-core/109.07.00/individual/ > > And the documentation: > > https://ocaml.janestreet.com/ocaml-core/109.07.00/doc/ > > All packages are available through opam. > > ** The Core suite ** > > The Core suite includes a variety of useful libraries, including: > > - Core: the heart of the standard library. > - Several useful syntax extensions > - type-conv: a library for building type-driven syntax extensions > - sexplib: a library for handling s-expressions, and a syntax > extension for auto-generating conversions between OCaml types and > s-expressions > - bin-prot: a syntax-extensions for generating > - pipebang > - variantslib > - comparelib > - fieldslib > - Async: a monadic concurrency library. > - Core_extended: extra components that are not as closely vetted or as > stable as Core. This includes, Shell, an interface for interacting > with the UNIX shell, and Command, a command-line parsing library. > > ** Repositories ** > > The official repositories for the Core libraries are now located on > the "janestreet" organisation on github and the "janestreet" team on > bitbucket. > > github: https://github.com/janestreet > bitbucket: https://bitbucket.org/janestreet > github home page: http://janestreet.github.com/ > > We changed the way we are exporting our source tree; there will now be > only one visible commit per release and project. Hopefully this > simpiflied process will allow more frequent updates. > > ** Contribution ** > > If you want to contribute to core the preferred way is to submit a > pull-request, which won't be merged in the end but will be used for > working on the changes before they are accepted and added to our > development process for integration in a future release. > > ** Changes ** > > He is a list of changes since the previous public release (108.08.00): > > - Switched to OCaml 4.0. > - Async: > - Add a [~perm] argument to [Writer.open_file] to set the file > permissions in the same way [Unix.openfile] does. > - Added [Async.Unix.unsetenv]. > - Fixed a bug in [Reader] that in some situations would make the > reader unusable after an error in user code (e.g. a failed sexp > conversion). > - Fixed a bug in [Writer] that manifests when scheduling bigstrings > with non-zero pos parameter. > - Fixed a bug in [Scheduler.go], which previously behaved incorrectly > if an exception had been raised to the main monitor prior to > [Scheduler.go] being called. The exception is now dealt with > immediately, rather than running a cycle. > - Exposed the type and value [Async.Config.t] as sexpable. > - Improved error message when a user requests async to manage a file > descriptor that it is already managing. > - Improved error message when creation of the async scheduler fails. > - Added [val _squelch_unused_module_warning_] to [Async.Std]. > - Made [Reader.load_sexp{,s}] handle exceptions other than > [Of_sexp_error]. > - Fixed a bug in async's handing of file descriptors -- a missed check > for a file descriptor having been closed. > - Added [Writer.set_buffer_age_limit]. > - Improved the performance of [Deferred.Queue] by changing the > implementation to use lists rather than arrays, which reduces gc > promotion. > - Added [?should_close_file_descriptor:bool] argument to [Async.Unix.close]. > - Moved the implementation of finalizers from Async_unix to > Async_core. This makes it possible to unit test finalizers (and > things using them) using only the Async_core scheduler. > - Changed the async scheduler so that if there are no upcoming events, > it times out in 50ms rather than waiting forever. > - Added =Monad_sequence.iteri=, which in turn adds it to: > =Deferred.Array=, =Deferred.List=, and =Deferred.Queue=. > - Added =Pipe.init=, which is analogous to =Deferred.create=. > - Improved the performance of =Pipe.iter{,_without_pushback}=. > - Improved =Reader.read_one_chunk_at_a_time_until_eof=: > - the callback need not consume everything > - add =`Eof_with_unconsumed_data= as a possible result > - grow internal buffer of the reader when needed > - Added =Shutdown.exit=, removed =Shutdown.shutdown_and_raise=. > - Added =Scheduler.force_current_cycle_to_end=. > - Core: > - Added [Char.of_string]. > - Fix [Backtrace.get], which was broken in 109.00, with the > switch to OCaml 4.0. > - Added [Heap.iter_el]. > - Updated [Core.Unix.stat] so that access, modify, and change times > have nanosecond precision. > - Fixed a bug in [Nano_mutex.invariant]. > - Simplified the implementation of [with_return] using a local > explicit polymorphic type variable. > - Added [Map.symmetric_diff], for returning a list of differences > between two maps. It has a fast-path implementation for maps that > share a large amount of their internal structure. > - Added a number of functions to =Bounded_int_table=: =equal=, > =exists{,i}=, =for_all{,i}=, =filter_map{,i}=, =map{,i}=. Also > added a functor, =Bounded_int_table.With_key=, that makes a > bounded-int table binable and sexpable, and adds =of_alist= and > =of_alist_exn=. > - Added =Doubly_linked.iter_elt= and =Bag.iter_elt=. > - Added =module Invariant=, which defines signatures that are to > be included in other signatures to ensure a consistent interface to > invariant-style functions. > - Added =module Ordering=, which defines: > =type t = Less | Equal | Greater= > > -- > Jeremie Dimino, for the Core team > > -- > You received this message because you are subscribed to the Google Groups "ocaml-core" group. > To unsubscribe from this group and stop receiving emails from it, send an email to ocaml-core+unsubscribe at googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. > > -- You received this message because you are subscribed to the Google Groups "ocaml-core" group. To unsubscribe from this group and stop receiving emails from it, send an email to ocaml-core+unsubscribe at googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. From anil at recoil.org Thu Jan 31 10:26:18 2013 From: anil at recoil.org (Anil Madhavapeddy) Date: Thu, 31 Jan 2013 10:26:18 +0000 Subject: [ANN] Core Suite 109.07.00 released In-Reply-To: References: <632F0809-EABE-47DA-80B5-E6509E489DCF@recoil.org> Message-ID: <55EB08B7-A669-4D5C-B070-0C25BD0FAA60@recoil.org> On 31 Jan 2013, at 01:07, Yaron Minsky wrote: > On Wed, Jan 30, 2013 at 7:37 PM, Anil Madhavapeddy wrote: >> [-ocaml list] >> >> A few incompatibilities so far: >> >> - MacOS X broken due to configuration errors: >> https://github.com/janestreet/core/pull/1 >> >> - Warnings-as-errors enabled in release tarballs, which needs to be disabled >> https://github.com/OCamlPro/opam-repository/issues/353 > > Eeek. Looks like we need to tune our process just a bit. > >> - This is all intended to be 4.00.0+ only, right? I've added a version >> constraint on type_conv which breaks on 3.12.1 atm. > > Yes, this is 4.00 only. 109 is where we stopped support 3.12.1. I've pushed a temporary fix to OPAM to restrict the 109.* versions to be selected on Linux only, which at least lets me get my MacOS X development environment back. Finer grain constraints are possible but put a strain on the solver, which Thomas is currently looking at. Jeremie, we can also hook up the OPAM test setup to test a pull request before merge. We should probably do this before any future upgrades. One way to do this is for you to tag an ~rc1 to the version (which will be ordered correctly by the version comparator). If it passes, you can just re-tag on your end to the final version, and it can be merged without further tests. -anil -- You received this message because you are subscribed to the Google Groups "ocaml-core" group. To unsubscribe from this group and stop receiving emails from it, send an email to ocaml-core+unsubscribe at googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. From anil at recoil.org Thu Jan 31 10:45:15 2013 From: anil at recoil.org (Anil Madhavapeddy) Date: Thu, 31 Jan 2013 10:45:15 +0000 Subject: [ANN] Core Suite 109.07.00 released In-Reply-To: References: <632F0809-EABE-47DA-80B5-E6509E489DCF@recoil.org> <55EB08B7-A669-4D5C-B070-0C25BD0FAA60@recoil.org> Message-ID: On 31 Jan 2013, at 10:42, Sylvain Le Gall wrote: > > I tend to do things the other way: > - have a builder (I use jenkins) > - if the build and every tests succeed, provide enough information in a file called dist/tag (e.g. the checksum of HEAD for git, or a patch for darcs) > - when ready, just wget the latest successful dist/tag and use it to tag your tree > - if needed use a matrix project to build on different system (Mac OS X, Debian Squeeze 32bits, Debian Squeeze 64 bits, Windows), the success of the build in this case will be linked to the success of every platform That's not compatible with the Jane Street release process. They have to push an RC to OPAM for us to be able to kick off tests. -anil -- You received this message because you are subscribed to the Google Groups "ocaml-core" group. To unsubscribe from this group and stop receiving emails from it, send an email to ocaml-core+unsubscribe at googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. From markus.mottl at gmail.com Thu Jan 31 16:14:46 2013 From: markus.mottl at gmail.com (Markus Mottl) Date: Thu, 31 Jan 2013 11:14:46 -0500 Subject: [ANN] Core Suite 109.07.00 released In-Reply-To: References: Message-ID: Btw., I like the new repository setup better than the previous one. I think keeping sub-projects separate instead of having one giant "core" project will make it more manageable to keep track of contributions. Using the pull request feature instead of patches to the mailing list should also help make the contribution process more efficient and transparent. Thanks! On Wed, Jan 30, 2013 at 5:12 PM, Jeremie Dimino wrote: > I'm pleased to announce the 109.07.00 release of the Core suite of > libraries. Core is an industrial strength alternative to OCaml's > standard library. > > Tarballs can be found here: > > https://ocaml.janestreet.com/ocaml-core/109.07.00/individual/ > > And the documentation: > > https://ocaml.janestreet.com/ocaml-core/109.07.00/doc/ > > All packages are available through opam. > > ** The Core suite ** > > The Core suite includes a variety of useful libraries, including: > > - Core: the heart of the standard library. > - Several useful syntax extensions > - type-conv: a library for building type-driven syntax extensions > - sexplib: a library for handling s-expressions, and a syntax > extension for auto-generating conversions between OCaml types and > s-expressions > - bin-prot: a syntax-extensions for generating > - pipebang > - variantslib > - comparelib > - fieldslib > - Async: a monadic concurrency library. > - Core_extended: extra components that are not as closely vetted or as > stable as Core. This includes, Shell, an interface for interacting > with the UNIX shell, and Command, a command-line parsing library. > > ** Repositories ** > > The official repositories for the Core libraries are now located on > the "janestreet" organisation on github and the "janestreet" team on > bitbucket. > > github: https://github.com/janestreet > bitbucket: https://bitbucket.org/janestreet > github home page: http://janestreet.github.com/ > > We changed the way we are exporting our source tree; there will now be > only one visible commit per release and project. Hopefully this > simpiflied process will allow more frequent updates. > > ** Contribution ** > > If you want to contribute to core the preferred way is to submit a > pull-request, which won't be merged in the end but will be used for > working on the changes before they are accepted and added to our > development process for integration in a future release. > > ** Changes ** > > He is a list of changes since the previous public release (108.08.00): > > - Switched to OCaml 4.0. > - Async: > - Add a [~perm] argument to [Writer.open_file] to set the file > permissions in the same way [Unix.openfile] does. > - Added [Async.Unix.unsetenv]. > - Fixed a bug in [Reader] that in some situations would make the > reader unusable after an error in user code (e.g. a failed sexp > conversion). > - Fixed a bug in [Writer] that manifests when scheduling bigstrings > with non-zero pos parameter. > - Fixed a bug in [Scheduler.go], which previously behaved incorrectly > if an exception had been raised to the main monitor prior to > [Scheduler.go] being called. The exception is now dealt with > immediately, rather than running a cycle. > - Exposed the type and value [Async.Config.t] as sexpable. > - Improved error message when a user requests async to manage a file > descriptor that it is already managing. > - Improved error message when creation of the async scheduler fails. > - Added [val _squelch_unused_module_warning_] to [Async.Std]. > - Made [Reader.load_sexp{,s}] handle exceptions other than > [Of_sexp_error]. > - Fixed a bug in async's handing of file descriptors -- a missed check > for a file descriptor having been closed. > - Added [Writer.set_buffer_age_limit]. > - Improved the performance of [Deferred.Queue] by changing the > implementation to use lists rather than arrays, which reduces gc > promotion. > - Added [?should_close_file_descriptor:bool] argument to [Async.Unix.close]. > - Moved the implementation of finalizers from Async_unix to > Async_core. This makes it possible to unit test finalizers (and > things using them) using only the Async_core scheduler. > - Changed the async scheduler so that if there are no upcoming events, > it times out in 50ms rather than waiting forever. > - Added =Monad_sequence.iteri=, which in turn adds it to: > =Deferred.Array=, =Deferred.List=, and =Deferred.Queue=. > - Added =Pipe.init=, which is analogous to =Deferred.create=. > - Improved the performance of =Pipe.iter{,_without_pushback}=. > - Improved =Reader.read_one_chunk_at_a_time_until_eof=: > - the callback need not consume everything > - add =`Eof_with_unconsumed_data= as a possible result > - grow internal buffer of the reader when needed > - Added =Shutdown.exit=, removed =Shutdown.shutdown_and_raise=. > - Added =Scheduler.force_current_cycle_to_end=. > - Core: > - Added [Char.of_string]. > - Fix [Backtrace.get], which was broken in 109.00, with the > switch to OCaml 4.0. > - Added [Heap.iter_el]. > - Updated [Core.Unix.stat] so that access, modify, and change times > have nanosecond precision. > - Fixed a bug in [Nano_mutex.invariant]. > - Simplified the implementation of [with_return] using a local > explicit polymorphic type variable. > - Added [Map.symmetric_diff], for returning a list of differences > between two maps. It has a fast-path implementation for maps that > share a large amount of their internal structure. > - Added a number of functions to =Bounded_int_table=: =equal=, > =exists{,i}=, =for_all{,i}=, =filter_map{,i}=, =map{,i}=. Also > added a functor, =Bounded_int_table.With_key=, that makes a > bounded-int table binable and sexpable, and adds =of_alist= and > =of_alist_exn=. > - Added =Doubly_linked.iter_elt= and =Bag.iter_elt=. > - Added =module Invariant=, which defines signatures that are to > be included in other signatures to ensure a consistent interface to > invariant-style functions. > - Added =module Ordering=, which defines: > =type t = Less | Equal | Greater= > > -- > Jeremie Dimino, for the Core team > > -- > You received this message because you are subscribed to the Google Groups "ocaml-core" group. > To unsubscribe from this group and stop receiving emails from it, send an email to ocaml-core+unsubscribe at googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. > > -- Markus Mottl http://www.ocaml.info markus.mottl at gmail.com -- You received this message because you are subscribed to the Google Groups "ocaml-core" group. To unsubscribe from this group and stop receiving emails from it, send an email to ocaml-core+unsubscribe at googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. From jdimino at janestreet.com Thu Jan 31 16:37:42 2013 From: jdimino at janestreet.com (Jeremie Dimino) Date: Thu, 31 Jan 2013 11:37:42 -0500 Subject: [ANN] Core Suite 109.07.00 released In-Reply-To: <632F0809-EABE-47DA-80B5-E6509E489DCF@recoil.org> References: <632F0809-EABE-47DA-80B5-E6509E489DCF@recoil.org> Message-ID: On Wed, Jan 30, 2013 at 7:37 PM, Anil Madhavapeddy wrote: > - MacOS X broken due to configuration errors: > https://github.com/janestreet/core/pull/1 I'll try to fix this. > - Warnings-as-errors enabled in release tarballs, which needs to be disabled > https://github.com/OCamlPro/opam-repository/issues/353 It will be disabled in the next release. For now I added patches in opam packages to disable -warn-error. -- You received this message because you are subscribed to the Google Groups "ocaml-core" group. To unsubscribe from this group and stop receiving emails from it, send an email to ocaml-core+unsubscribe at googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. From sylvain at le-gall.net Thu Jan 31 10:42:02 2013 From: sylvain at le-gall.net (Sylvain Le Gall) Date: Thu, 31 Jan 2013 11:42:02 +0100 Subject: [ANN] Core Suite 109.07.00 released In-Reply-To: <55EB08B7-A669-4D5C-B070-0C25BD0FAA60@recoil.org> References: <632F0809-EABE-47DA-80B5-E6509E489DCF@recoil.org> <55EB08B7-A669-4D5C-B070-0C25BD0FAA60@recoil.org> Message-ID: 2013/1/31 Anil Madhavapeddy > On 31 Jan 2013, at 01:07, Yaron Minsky wrote: > > > On Wed, Jan 30, 2013 at 7:37 PM, Anil Madhavapeddy > wrote: > >> [-ocaml list] > >> > >> A few incompatibilities so far: > >> > >> - MacOS X broken due to configuration errors: > >> https://github.com/janestreet/core/pull/1 > >> > >> - Warnings-as-errors enabled in release tarballs, which needs to be > disabled > >> https://github.com/OCamlPro/opam-repository/issues/353 > > > > Eeek. Looks like we need to tune our process just a bit. > > > >> - This is all intended to be 4.00.0+ only, right? I've added a version > >> constraint on type_conv which breaks on 3.12.1 atm. > > > > Yes, this is 4.00 only. 109 is where we stopped support 3.12.1. > > I've pushed a temporary fix to OPAM to restrict the 109.* versions to > be selected on Linux only, which at least lets me get my MacOS X > development > environment back. > > Finer grain constraints are possible but put a strain on the solver, which > Thomas is currently looking at. > > Jeremie, we can also hook up the OPAM test setup to test a pull request > before > merge. We should probably do this before any future upgrades. One way to > do > this is for you to tag an ~rc1 to the version (which will be ordered > correctly > by the version comparator). If it passes, you can just re-tag on your end > to > the final version, and it can be merged without further tests. I tend to do things the other way: - have a builder (I use jenkins) - if the build and every tests succeed, provide enough information in a file called dist/tag (e.g. the checksum of HEAD for git, or a patch for darcs) - when ready, just wget the latest successful dist/tag and use it to tag your tree - if needed use a matrix project to build on different system (Mac OS X, Debian Squeeze 32bits, Debian Squeeze 64 bits, Windows), the success of the build in this case will be linked to the success of every platform i.e. you always tests everything using jenkins and you always provide information to tag. This allows to be always ready to do a release... Example: http://deci.ovh.le-gall.net:8080/job/gildor478-oasis/lastSuccessfulBuild/artifact/dist/tag browse: http://deci.ovh.le-gall.net:8080/job/gildor478-oasis/ Regards Sylvain -- You received this message because you are subscribed to the Google Groups "ocaml-core" group. To unsubscribe from this group and stop receiving emails from it, send an email to ocaml-core+unsubscribe at googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sylvain at le-gall.net Thu Jan 31 11:04:50 2013 From: sylvain at le-gall.net (Sylvain Le Gall) Date: Thu, 31 Jan 2013 12:04:50 +0100 Subject: [ANN] Core Suite 109.07.00 released In-Reply-To: References: <632F0809-EABE-47DA-80B5-E6509E489DCF@recoil.org> <55EB08B7-A669-4D5C-B070-0C25BD0FAA60@recoil.org> Message-ID: 2013/1/31 Anil Madhavapeddy > On 31 Jan 2013, at 10:42, Sylvain Le Gall wrote: > > > > I tend to do things the other way: > > - have a builder (I use jenkins) > > - if the build and every tests succeed, provide enough information in a > file called dist/tag (e.g. the checksum of HEAD for git, or a patch for > darcs) > > - when ready, just wget the latest successful dist/tag and use it to tag > your tree > > - if needed use a matrix project to build on different system (Mac OS X, > Debian Squeeze 32bits, Debian Squeeze 64 bits, Windows), the success of the > build in this case will be linked to the success of every platform > > That's not compatible with the Jane Street release process. They have to > push an RC to OPAM for us to be able to kick off tests. > I probably have missed a couple of email about JS release process... ;-) Note that this way of doing thing doesn't prevent to use the dist/tag to tag a RC rather than doing a public release. > > -anil > > -- > You received this message because you are subscribed to the Google Groups > "ocaml-core" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to ocaml-core+unsubscribe at googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. > > > -- You received this message because you are subscribed to the Google Groups "ocaml-core" group. To unsubscribe from this group and stop receiving emails from it, send an email to ocaml-core+unsubscribe at googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -------------- next part -------------- An HTML attachment was scrubbed... URL: