The issue of the Windows console window has come up from time to time and I've had another look at the code and made a few minor changes.
The first change is to provide an option to "./configure" to allow Poly/ML to be built as a "console" application rather than a "windows" application. Setting "--disable-windows-gui" passes -mconsole to the linker rather than -mwindows. This sets the appropriate bits in the EXE header. As well as affecting the linking of "poly" itself it also affects executables built with "polyc". The default remains "--enable-windows-gui" to build as a "windows" application.
The second change is that when Poly is built as a Windows application, the default, it puts up a GUI window only if standard output has not been provided. Previously it put up a GUI window unless both standard input and standard output were provided. If it creates a GUI window for output it also uses it for input unless there is an explicit standard input provided.
It may be helpful to provide a bit of background. I have the impression that there are two different classes of users when it comes to Poly/ML on Windows. Users from a Windows background expect the application to come with an installer, a Windows GUI and to support the standard copy-and-paste, in particular with the standard control-C/control-V key bindings. Users from a Unix background are much more used to running applications in a console window and are more likely to build applications from source. The problem is to satisfy both classes of user.
Executables in Windows can be either "windows" or "console" applications depending on the "subsystem" setting in the EXE header. "console" applications are always started with a cmd.exe-style console unless they're already in a console. "windows" applications are expected to create their own GUI. My impression is that "console" applications are regarded as a legacy of DOS and not well supported. That's why I've made "windows" mode the default. Nevertheless there may be cases where someone would like to build "poly" as a console application which is the reason for adding the option.
David
On Tue, Sep 15, 2015 at 2:34 PM, David Matthews <David.Matthews at prolingua.co.uk> wrote:
Executables in Windows can be either "windows" or "console" applications depending on the "subsystem" setting in the EXE header. "console" applications are always started with a cmd.exe-style console unless they're already in a console. "windows" applications are expected to create their own GUI. My impression is that "console" applications are regarded as a legacy of DOS and not well supported. That's why I've made "windows" mode the default. Nevertheless there may be cases where someone would like to build "poly" as a console application which is the reason for adding the option.
FWIW, here's my preferences wrt PolyML on windows:
- I appreciate prebuilt binaries, as I often don't have all the tools needed to built things myself on windows.
- I don't care if there's an installer or not as long as the steps needed to install something are clear.
- I have no use of "windows" applications for a language system such as polyml. I expect to run sml interpreters in an emacs buffer using inferior-SML, just like I do on Unix. That's the reason why up to now I only used PolyML rarely, mostly for comparisons against sml/nj (whose prebuilt binary is a console application that I can run from emacs, and hence is a million times more pleasing to use for me, despite being slower than PolyML on most of the programs I care about).
- for people who don't use emacs there would be little difference between a console and a window application, I think. In both cases they would get a basic window with the interpreter prompt and not much more.
Thank you!
On 15/09/2015 20:35, Pierpaolo Bernardi wrote:
- I have no use of "windows" applications for a language system such
as polyml. I expect to run sml interpreters in an emacs buffer using inferior-SML, just like I do on Unix. That's the reason why up to now I only used PolyML rarely, mostly for comparisons against sml/nj (whose prebuilt binary is a console application that I can run from emacs, and hence is a million times more pleasing to use for me, despite being slower than PolyML on most of the programs I care about).
How does emacs run the ML? If it runs it as a process with standard input and standard output through pipes then I would expect Poly/ML to run perfectly well and not produce its GUI. I use Poly/ML that way with my own Windows IDE and the testing version of Isabelle works that way as well.
- for people who don't use emacs there would be little difference
between a console and a window application, I think. In both cases they would get a basic window with the interpreter prompt and not much more.
I personally find Windows console applications painful to use, primarily because it is so difficult to copy and paste. Cygwin and Msys with rxvt at least support copy and paste with the middle button.
David
On Tue, Sep 15, 2015 at 10:19 PM, David Matthews <David.Matthews at prolingua.co.uk> wrote:
On 15/09/2015 20:35, Pierpaolo Bernardi wrote:
How does emacs run the ML? If it runs it as a process with standard input and standard output through pipes then I would expect Poly/ML to run perfectly well and not produce its GUI. I use Poly/ML that way with my own Windows IDE and the testing version of Isabelle works that way as well.
You are right! It was some time I hadn't used PolyML and I was misremembering. The only problem of PolyML under Emacs is that it does not print any prompt. Sorry.
I personally find Windows console applications painful to use, primarily because it is so difficult to copy and paste. Cygwin and Msys with rxvt at least support copy and paste with the middle button.
I use emacs as my OS, so I'm not bothered much by windows terminal shortcomings :)
Cheers P.
On 15/09/2015 21:42, Pierpaolo Bernardi wrote:
On Tue, Sep 15, 2015 at 10:19 PM, David Matthews <David.Matthews at prolingua.co.uk> wrote:
On 15/09/2015 20:35, Pierpaolo Bernardi wrote:
How does emacs run the ML? If it runs it as a process with standard input and standard output through pipes then I would expect Poly/ML to run perfectly well and not produce its GUI. I use Poly/ML that way with my own Windows IDE and the testing version of Isabelle works that way as well.
You are right! It was some time I hadn't used PolyML and I was misremembering. The only problem of PolyML under Emacs is that it does not print any prompt. Sorry.
You need the "-i" option on the command line. By default Poly/ML only prints the prompt if the input is a console under both Windows and Unix. If the input stream is a pipe you need to tell it that you have an interactive input.
David
On Tue, Sep 15, 2015 at 10:49 PM, David Matthews <David.Matthews at prolingua.co.uk> wrote:
You need the "-i" option on the command line. By default Poly/ML only prints the prompt if the input is a console under both Windows and Unix. If the input stream is a pipe you need to tell it that you have an interactive input.
Yes, -i indeed works.
Thank you!
-
David.Matthews＠prolingua.co.uk -
olopierpa＠gmail.com