From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by walapai.inria.fr (8.13.6/8.13.6) with ESMTP id q25EWfS8028864 for ; Mon, 5 Mar 2012 15:32:41 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoYCAMbNVE/RVdS0kGdsb2JhbABDDqJvkVUIIgEBAQEJCQ0HFAQjgX0BAQEDARICLAEbEgYFAQMBCwYFCwMKDRYLIgERAQUBCgQBDQYTEgIOh2AFC5pFCotygnGEcz+IdAEFC5BSBJU+hxuHGT2DTTg X-IronPort-AV: E=Sophos;i="4.73,534,1325458800"; d="scan'208";a="134436489" Received: from mail-wi0-f180.google.com ([209.85.212.180]) by mail4-smtp-sop.national.inria.fr with ESMTP/TLS/RC4-SHA; 05 Mar 2012 15:32:36 +0100 Received: by wibhm9 with SMTP id hm9so2380959wib.39 for ; Mon, 05 Mar 2012 06:32:35 -0800 (PST) Received-SPF: pass (google.com: domain of gabriel.scherer@gmail.com designates 10.216.136.131 as permitted sender) client-ip=10.216.136.131; Authentication-Results: mr.google.com; spf=pass (google.com: domain of gabriel.scherer@gmail.com designates 10.216.136.131 as permitted sender) smtp.mail=gabriel.scherer@gmail.com; dkim=pass header.i=gabriel.scherer@gmail.com Received: from mr.google.com ([10.216.136.131]) by 10.216.136.131 with SMTP id w3mr3606993wei.15.1330957955514 (num_hops = 1); Mon, 05 Mar 2012 06:32:35 -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=uaAjmz+1c/RcT8LzNvAbT8uj8QsopQhSTW6wmSw8ANM=; b=PH1i1/4ka93UGwxm6EJIGRyvAJKE1xBRPWlmOAv7B9WZ+AmgZVFxRgeVeai0yFZ6Y1 itiyRE21jidUwPAJ+X3vc5VR/FIGC5OWPk/yjyYPOvpVSBB6LxvUWw7pOlNy0ila8lwD 18jyREtEojjhGmsUf3eAJsrPy2X7UZT65KBeuYHqiWqyKV7RTiUCFOH1XrMt+1uTem1Q eSxG6h2v9/96dc18cuYys1b223yDHWFpWKfXP28QHLyt6U+gACeeZ4TL8smfu4V+mR1p PP3BZhqpYffizF9Q0ki9Ybe1XNh4U43piRuxAxZsmLSnMCs2kRvpzzF5GtAjPqsUbiW5 6nzg== Received: by 10.216.136.131 with SMTP id w3mr2892608wei.15.1330957955413; Mon, 05 Mar 2012 06:32:35 -0800 (PST) MIME-Version: 1.0 Received: by 10.227.200.85 with HTTP; Mon, 5 Mar 2012 06:31:55 -0800 (PST) In-Reply-To: <20120305134624.GA5718@mulga.csse.unimelb.edu.au> References: <20120305134624.GA5718@mulga.csse.unimelb.edu.au> From: Gabriel Scherer Date: Mon, 5 Mar 2012 15:31:55 +0100 Message-ID: To: Jeff Schultz Cc: caml-list 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 q25EWfS8028864 Subject: Re: [Caml-list] [community poll for PR#5312] Do some OCaml Windows users still use the @responsefile feature? > 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. On Mon, Mar 5, 2012 at 2:46 PM, Jeff Schultz wrote: > On Mon, Mar 05, 2012 at 11:46:08AM +0100, Gabriel Scherer wrote: >> According to our Windows spies, the command-line restrictions are >> nowadays very reasonable: 8K for cmd.com, and 32K internally. Maybe >> the @responsefile feature has outlived its use, and this bug could be >> fixed by simply removing the @-files expansion phase of the runtime. > > 8K is not much. > >> This change would however affect all user programs, so it should not >> be taken lightly; it could break your programs. > >> What do OCaml Windows user think? Do you still rely on @reponsefile? >> Please complain if you do -- or your users do -- and don't hesitate to >> pass the question to off-list OCaml Windows users. > > I stopped using OCaml for new development *because* of the pain it > caused on MSWIN, so my opinion is probably not very valuable. > > It looks to me like you could simply disable the feature for arguments > following -w.  However, if you want to remove the feature, I suggest > that you do so in three stages: > >    1.  Disable the @responsefile feature and provide a command line >        flag to reenable it.  Warn if this conflicts with the -w @a >        style of options. >    2.  In a later release, remove the code, but make the flag print >        an appropriate diagnostic. >    3.  In an even later release, remove the flag completely. > > The time between the first two steps should be determined by the > response to the first step. > > This is the standard evolution: make people notice that you are taking > a feature away, but let them keep using it, followed by taking it > away, but telling them it's gone, followed by pretending it never > existed. > > It's good that you're adding the desirable preliminary of asking > first. > > >    Jeff Schultz > > -- > Caml-list mailing list.  Subscription management and archives: > https://sympa-roc.inria.fr/wws/info/caml-list > Beginner's list: http://groups.yahoo.com/group/ocaml_beginners > Bug reports: http://caml.inria.fr/bin/caml-bugs >