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 q25FplCE002754 for ; Mon, 5 Mar 2012 16:51:47 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ar4BALngVE/RVdS0kGdsb2JhbAApGg60UQgiAQEBAQkJDQcUBCOBfQEBAQMBEgIsARsYBQEDAQsGBQsDCiMLIgERAQUBDgENBhMUBweHYAULKaF3CotygnGEfD+BDAEFC5BSBJU+hxuDfYMcPYNNOA X-IronPort-AV: E=Sophos;i="4.73,534,1325458800"; d="scan'208";a="147621918" Received: from mail-wi0-f180.google.com ([209.85.212.180]) by mail1-smtp-roc.national.inria.fr with ESMTP/TLS/RC4-SHA; 05 Mar 2012 16:51:42 +0100 Received: by wibhm9 with SMTP id hm9so2472840wib.39 for ; Mon, 05 Mar 2012 07:51:42 -0800 (PST) Received-SPF: pass (google.com: domain of gabriel.scherer@gmail.com designates 10.180.95.34 as permitted sender) client-ip=10.180.95.34; Authentication-Results: mr.google.com; spf=pass (google.com: domain of gabriel.scherer@gmail.com designates 10.180.95.34 as permitted sender) smtp.mail=gabriel.scherer@gmail.com; dkim=pass header.i=gabriel.scherer@gmail.com Received: from mr.google.com ([10.180.95.34]) by 10.180.95.34 with SMTP id dh2mr16230799wib.15.1330962702339 (num_hops = 1); Mon, 05 Mar 2012 07:51:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=irBKPsGgSfbtPiua2ZgfxRdm4PV2NG8STSJ7Dcc/kYQ=; b=XuUBeiXYLyf2Uaqt37uLpjvepLnsJTfQqQ0dOSzroxCluRbdYf+gUv/z3/PoHJ/zyD bweiHxFZRy8UVrvg4d8N5ws+p+N46O1k/LN4tpOqDpzWe3S89jaGaJMzB25zq14QQ39q opXbB2tLZpdAFGRn0jTzNYJIAyVNs8PHFnjPJo3F8kFjURY7EVmeHfxE6+KXWPN+8m+Z dyoPLoGAHTXdSLK/Oc0qLNePqT71YStMVh5f5q9ufDTFmtcyInFa5r1IW2O+ctsqKVqK Qwz/lbjtDpkHJKMWRuuJ2NoGZf65kWkbQqZImnge67e8H6F0U/g9C2VbHcmAbaoeTuQm P8gQ== Received: by 10.180.95.34 with SMTP id dh2mr12891509wib.15.1330962702207; Mon, 05 Mar 2012 07:51:42 -0800 (PST) MIME-Version: 1.0 Received: by 10.227.200.85 with HTTP; Mon, 5 Mar 2012 07:51:02 -0800 (PST) In-Reply-To: <20120305151021.GA26422@mulga.csse.unimelb.edu.au> References: <20120305134624.GA5718@mulga.csse.unimelb.edu.au> <20120305151021.GA26422@mulga.csse.unimelb.edu.au> From: Gabriel Scherer Date: Mon, 5 Mar 2012 16:51:02 +0100 Message-ID: To: Jeff Schultz Cc: caml-list@yquem.inria.fr Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by walapai.inria.fr id q25FplCE002754 Subject: Re: [Caml-list] [community poll for PR#5312] Do some OCaml Windows users still use the @responsefile feature? > One could probably make it work, but it would > involve modifying the compiler programs to say "turn @-files > processing off, I'll process them myself" and it seems that it's not > worth the effort? I think that could only be done if there was a way to disable @-files expansion in the runtime (not only for the compiler programs), so in any case one would need to implement your "step 1". > In any case, does the staged feature-abandonment proposal make sense? I'm not the qualified person to answer -- I just wrote and sent this poll request to lighten the OCaml maintainers work -- but it looks reasonable as a perfectionist scenario. Due to the lack of workforce, we may end up with a "reduced effort" solution such as simply removing the feature and duly noting it in the Changelog. We'll see, and it depends on what other feedback there is. By looking at the code (byterun/main.c and asmrun/main.c), it looks simpler to enable/disable the @-expansion based on CAMLRUNPARAM as Dimtry suggested, but that's a detail. Thanks for your feedback! Regarding your larger remark on Ocaml on Windows, the situation is unfortunate -- due mostly to the lack of Windows-informed people ready to step up and help fixing the issues -- but there have been efforts of people trying to make the situation better. For example, Jonathan Protzenko has a Windows installer for 3.12 that should work out of the box -- for the compilers only, of course, this doesn't fix the larger issue of third-party OCaml software. I'm sure he, and other people working on OCaml/Windows, would welcome precise feedback on things that don't work; the bugtracker is the right place to report issues on the ocaml compilers -- there is a specific "ocaml windows" category -- and for third-party programs you should not hesitate to contact the authors, or ask the caml-list. http://protz.github.com/ocaml-installer/ http://caml.inria.fr/mantis/my_view_page.php On Mon, Mar 5, 2012 at 4:10 PM, Jeff Schultz wrote: > On Mon, Mar 05, 2012 at 03:31:55PM +0100, Gabriel Scherer wrote: >> > It looks to me like you could simply disable the feature for arguments >> > following -w. >> >> If I understand the situation correctly, this approach is not >> currently an option, as the @responsefile expansion is done by the >> OCaml runtime -- affects all programs, before they process their >> arguments -- while the "-w" exception would only make sense for the >> compiler toolchains; there is no reason why an user program (that >> currently can use the @responsefile feature) would suddenly stop >> expanding @-files after a "-w", an option which may have completely >> different semantics in this program command-line interface. > > Oh, that's a pity.  One could probably make it work, but it would > involve modifying the compiler programs to say "turn @-files > processing off, I'll process them myself" and it seems that it's not > worth the effort? > > In any case, does the staged feature-abandonment proposal make sense? > > >    Jeff Schultz