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 q25IbQvN008307 for ; Mon, 5 Mar 2012 19:37:26 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvwFAG8HVU/U4xEJk2dsb2JhbABDDqJ2kV4iAQEBAQcLCwkUAySBfQEBBAFuBgUFCwUGDgoNFgtFBAENBhMJCAECB4dnCQe4L4oXhkYEjUMXmiI4gVQ X-IronPort-AV: E=Sophos;i="4.73,535,1325458800"; d="scan'208";a="147664221" Received: from moutng.kundenserver.de ([212.227.17.9]) by mail1-smtp-roc.national.inria.fr with ESMTP; 05 Mar 2012 19:37:21 +0100 Received: from office1.lan.sumadev.de (dslb-188-097-007-032.pools.arcor-ip.net [188.97.7.32]) by mrelayeu.kundenserver.de (node=mreu3) with ESMTP (Nemesis) id 0LwBgI-1SSX3a2IRy-0186HC; Mon, 05 Mar 2012 19:37:16 +0100 Received: from gps.dynxs.de (localhost [127.0.0.1]) by office1.lan.sumadev.de (Postfix) with ESMTP id A18D8C00CB; Mon, 5 Mar 2012 19:37:15 +0100 (CET) Received: from 178.4.234.245 (SquirrelMail authenticated user gerd) by gps.dynxs.de with HTTP; Mon, 5 Mar 2012 19:37:16 +0100 Message-ID: In-Reply-To: <20120305134624.GA5718@mulga.csse.unimelb.edu.au> References: <20120305134624.GA5718@mulga.csse.unimelb.edu.au> Date: Mon, 5 Mar 2012 19:37:16 +0100 From: "Gerd Stolpmann" To: "Jeff Schultz" Cc: "caml-list" User-Agent: SquirrelMail/1.4.21 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 (Normal) Importance: Normal X-Provags-ID: V02:K0:zRJqM2ZnbKSCnIxo2V4nOv5rlf8crqFSM9YkFfvW8QI k1cE27q2eF6DCDYcyEiBa97jsNnEznte6AitbDrU92j6+1wI4O tXYdK4CzBFveMAemX7fyfI1223/5ViPCYHGrY8PZh7TPuXCrUe x1WbIGQyw0BvrmNd7XvSCcTD8TN8PbjaZPfFAsgLwmSrHnABDP EQJdwchD1cWXyL9SiTCaUI9M3dYxFxR4GxWcBOuFY+IxppgpTM 8NuwcpDOe2/Vpc7RDluPOp2e9PjExF2F9gXJiYnun4qoasde12 aov4aTwQU6BTAxfe87wRczp3ysEYkKyS3bVvfPcCnANDnfI8S3 JZNio8qNV4ysT3xgUFxWSo57y/RmRSxnXJFNedXJh56H5H4zMG J66BRM5CSVVQw== Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by walapai.inria.fr id q25IbQvN008307 Subject: Re: [Caml-list] [community poll for PR#5312] Do some OCaml Windows users still use the @responsefile feature? > 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. I second here, although I never hit the limit on Windows. However, command-line args of several megabytes are not uncommon for big projects, especially when you call ocamlc with tons of libraries. Well, I never did that large projects under Windows, only under Linux. >> 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: I think a very first shot could be to require that the responsefile must be given as an absolute path (with drive letter, or as network path). This will syntactically disambiguate it from most other uses. Normally it points to the temp folder anyway, given as absolute path, so this additional requirement will hardly break programs. A cleaner solution would probably to move the responsefile implementation up to the Arg module, so that the user (a) sees it, and (b) can enable or disable it as needed. Gerd > > 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 > > > -- Gerd Stolpmann, Darmstadt, Germany gerd@gerd-stolpmann.de Creator of GODI and camlcity.org. Contact details: http://www.camlcity.org/contact.html Company homepage: http://www.gerd-stolpmann.de *** Searching for new projects! Need consulting for system *** programming in Ocaml? Gerd Stolpmann can help you.