From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by walapai.inria.fr (8.13.6/8.13.6) with ESMTP id pBCHn6R5005852 for ; Mon, 12 Dec 2011 18:49:07 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArgDADo+5k6K54gDgWdsb2JhbABDqDyCRyIBARYmJYFyAQEEATIBRhALISUPAkYGDQEHAhAFAodttUqLbQSUcYVLjF0 X-IronPort-AV: E=Sophos;i="4.71,340,1320620400"; d="scan'208";a="135078514" Received: from rouge.crans.org ([138.231.136.3]) by mail1-smtp-roc.national.inria.fr with ESMTP/TLS/ADH-AES256-SHA; 12 Dec 2011 18:49:01 +0100 Received: from localhost (localhost.crans.org [127.0.0.1]) by rouge.crans.org (Postfix) with ESMTP id 82CA185E3; Mon, 12 Dec 2011 18:48:59 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at crans.org Received: from rouge.crans.org ([10.231.136.3]) by localhost (rouge.crans.org [10.231.136.3]) (amavisd-new, port 10024) with LMTP id Iv1pWqRge45f; Mon, 12 Dec 2011 18:48:59 +0100 (CET) Received: from [152.81.3.42] (wencory.loria.fr [152.81.3.42]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by rouge.crans.org (Postfix) with ESMTPSA id A5E6285DC; Mon, 12 Dec 2011 18:48:58 +0100 (CET) Message-ID: <4EE63E88.40805@glondu.net> Date: Mon, 12 Dec 2011 18:48:56 +0100 From: =?ISO-8859-1?Q?St=E9phane_Glondu?= User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111114 Icedove/3.1.16 MIME-Version: 1.0 To: Xavier Leroy CC: caml-list@inria.fr References: <55531934-37A5-4CC5-AB67-20CE4CCE8269@googlemail.com> <4EE37070.4010702@inria.fr> In-Reply-To: <4EE37070.4010702@inria.fr> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Subject: Re: [Caml-list] OCaml maintenance status / community fork (again) Le 10/12/2011 15:45, Xavier Leroy a écrit : >> For example, have a look at PR/3746, a great example. It took almost >> 4 years(!) to update the ARM port to softfp (and EABI). At the time >> the issue was finally fixed, most ARM application boards were >> already shipping with VFP, so the port is lacking behind several >> years. > > It is a great example indeed, but of my dedication to supporting OCaml in > the long run. Yes, it took a long time, first because adapting ocamlopt to > a soft-FP model was absolutely not obvious (the code generator really wants > FP regs to hold FP values), second because I had to wait a long time before > an appropriate development and testing environment was available (namely, > Debian ARM EABI running inside QEMU), third because nobody really cared. > Your average maintainer would have given up at that point and canceled the > ARM port of OCaml because ARM's floating-point is a mess. I didn't and > spent one full week of my summer vacations recoding the ARM port instead. > [...] It looks more like you wouldn't accept any external help, which is quite contradictory with your complaining on not having a lot of time to dedicate to ocaml. There are people that are actually paid (or otherwise rewarded) to make all of Debian and Ubuntu (including ocaml) work optimally on ARM (smartphones, tablets, and stuff). So I agree with Benedikt's "lacking behind several years" point, but it shouldn't be taken as negatively as you do. I'm not saying that someone else would have come up with a better solution than yours :-) >> The relevant bug report PR/5404, which includes a backward >> compatible patch, is already waiting for a sign of life for 3 weeks >> now (maybe wait another 4 years to get the port fixed). > > More bile. What's so urgent about it? The next release of OCaml is 3-6 > months in the future; your suggestion will be examined by then. [...] It's still unclear to me whether this kind of patches are welcome. I've been recently approached by an armhf porter (other than Benedikt) interested in having an ocamlopt running there, but I told him to back off because I don't know whether needed changes would be merged. Once again, I don't say we would have come up with a working solution before the next release of OCaml, but the result (if any) would have already been tested and deployed in Debian (and/or Ubuntu) before an upstream submission. Of course, we could carry on our patches in a Debian-specific way (and we already do), but lack of upstream interest is very demotivational for further development. Cheers, -- Stéphane