From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.5 required=5.0 tests=AWL,HTML_MESSAGE autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by yquem.inria.fr (Postfix) with ESMTP id 0A1A8BBC1 for ; Sat, 3 May 2008 12:55:35 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AksDAOzgG0jAXQIniGdsb2JhbACCNzSPCAEBAQ8gkzGFVA X-IronPort-AV: E=Sophos;i="4.27,430,1204498800"; d="scan'208";a="12210933" Received: from concorde.inria.fr ([192.93.2.39]) by mail3-smtp-sop.national.inria.fr with ESMTP; 03 May 2008 12:55:34 +0200 Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by concorde.inria.fr (8.13.6/8.13.6) with ESMTP id m43AtYaV013185 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=OK) for ; Sat, 3 May 2008 12:55:34 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkECAOzgG0jRVcbneWdsb2JhbACCNzSPCAEBCwUCBAkPkzOFVA X-IronPort-AV: E=Sophos;i="4.27,430,1204498800"; d="scan'208";a="10342605" Received: from rv-out-0506.google.com ([209.85.198.231]) by mail2-smtp-roc.national.inria.fr with ESMTP; 03 May 2008 12:55:33 +0200 Received: by rv-out-0506.google.com with SMTP id k40so311458rvb.57 for ; Sat, 03 May 2008 03:55:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=MCPjICAb+qoqL1CcqVM9vfZq8PusAkQBlIdxuiXcIuw=; b=QbNAoAYOO2CBYrJaOZCMAob/J8ooEjapK0QPW+GjVgYTiRjLj8aDY/hFhN+xvWuP9dhqVkutVtrix2KP6mUUH514hh79Dy3GhTrMZcM8cPEQA5bC8b8gTCfgtYFRK1WS6c/hkbJPnscYiH7CvkIqBDiC/SOEI/Jxo4Ey+4Cj5hg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:references; b=dJeyBjARZfH5yWyPMl/tdVOBOHOq9T+5UCVJq/BsN31BJTjpxMAeJh2N4Syat9P3wHSLZSUJ/SZf+28CK2F5rb1nvudNFbPQhvvXs5fiQkrrQ22Vngl/4pQ3dLSY8eTIezLrYy3X9ySuU1/3cEMKuNjSLhcly/vjeMOH/95rp5k= Received: by 10.141.27.16 with SMTP id e16mr1800053rvj.141.1209812131566; Sat, 03 May 2008 03:55:31 -0700 (PDT) Received: by 10.141.159.12 with HTTP; Sat, 3 May 2008 03:55:31 -0700 (PDT) Message-ID: <891bd3390805030355s37541bf4he7e08443fa36c045@mail.gmail.com> Date: Sat, 3 May 2008 06:55:31 -0400 From: "Yaron Minsky" Reply-To: yminsky@gmail.com To: "Berke Durak" Subject: Re: [Caml-list] Core has landed Cc: caml-list In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_15749_27958447.1209812131562" References: <1209764381.8680.38.camel@nyc-qws-018.delacy.com> <1209771655.2934.25.camel@sobolev> <891bd3390805021651v677be0ddu58a53ccbbffc411a@mail.gmail.com> X-Miltered: at concorde with ID 481C44A6.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; yaron:01 minsky:01 yminsky:01 berke:01 durak:01 berke:01 durak:01 ocaml:01 ocaml:01 compiler:01 bytecode:01 compiler:01 bytecodes:01 bytecode:01 bytecodes:01 ------=_Part_15749_27958447.1209812131562 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Sat, May 3, 2008 at 4:07 AM, Berke Durak wrote: > That's wonderful! An impressive extended core library. Thanks a lot for > releasing that. It's like receiving a new toy. > > Now a few quick comments: > > - Bigstring: I guess those are more for I/O. The 16MB limit is not a > problem on 64-bit arhictectures. I/O, memory mapping, a few other things. > - POLL and NODELAY in Linux_ext: that's very welcome. > > - I guess JS isn't using Unicode. After all, EBCDIC should be good enoug= h > for stock tickers. A Unicode library would have been nice - otherwise we > should complete the one in ExtLib. It's true, we don't really use Unicode at all for the stuff we do. > - In tuple.ml, I find this worrying comment: > > The raison d'=EAtre for Space_safe_tuple is that OCaml doesn't prope= rly > free variables matched in tuple patterns. > > I didn't expect that, and that's quite annoying! Shouldn't that be fixed > in the > Ocaml compiler? We would prefer that too, but we haven't been able to convince anyone that it's worth doing. There are apparently some reasons that it's painful to fix in the bytecode compiler, and there's some reluctance to make the GC behavior be significantly different between native and bytecodes. > - piecewise_linear.ml: I wonder what these are for. Maybe for video > games? > > A very nice contribution to a "batteries included" standard library, > indeed. > -- > Berke Durak > > ------=_Part_15749_27958447.1209812131562 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Sat, May 3, 2008 at 4:07 AM, Berke Durak <berke.durak@gmail.com> wrote:
That's wonderful!  An impressive extended core library.  Than= ks a lot for
releasing that.  It's like receiving a new toy.
Now a few quick comments:

- Bigstring: I guess those are more f= or I/O.  The 16MB limit is not a problem on 64-bit arhictectures.

I/O, memory mapping, a few other things. 
 = ;
- POLL and= NODELAY in Linux_ext: that's very welcome.

- I guess JS isn't using Unicode.  After all, EBCDIC should be= good enough for stock tickers.  A Unicode library would have been nic= e - otherwise we should complete the one in ExtLib.
 =
It's true, we don't really use Unicode at all for the stuff we do.<= br> 
- = In tuple.ml, I find this = worrying comment:

  The raison d'=EAtre for Space_safe_tuple<N> is that OC= aml doesn't properly
  free variables matched in tuple patterns= .

I didn't expect that, and that's quite annoying!  Shouldn&= #39;t that be fixed in the
Ocaml compiler?

We would= prefer that too, but we haven't been able to convince anyone that it&#= 39;s worth doing.  There are apparently some reasons that it's pai= nful to fix in the bytecode compiler, and there's some reluctance to ma= ke the GC behavior be significantly different between native and bytecodes.=  
 
- piecewise_= linear.ml: I wonder what these are for.  Maybe for video games?
A very nice contribution to a "batteries included" standard l= ibrary, indeed. 
 
--
Berke Durak


------=_Part_15749_27958447.1209812131562--