David, On 20 May 2014, at 13:07, David Matthews <david.matth...@prolingua.co.uk> wrote:
> Rob, > > On 20/05/2014 06:57, Rob Arthan wrote: >> I agree that it wasn’t very clear whether this was thought to be a >> bug in the MinGW header files or not. > > I may have a look and see if this is something I can fix easily but there's > no point if they are going to fix in Mingw anyway. Last time I used Mingw I > didn't have this problem. As the work-around just involves setting an environment variable when you run configure, I don’t think it is worth spending much time on. > >> I would actually have expected the “GUI” to be a command prompt >> window. I.e., I would have expected poly to be a console application. >> This is how python comes, for example. Something that behaves like a >> console application is what cc on MinGW seems to give you if you >> don’t give it any of the Windows-specific command line options when >> you compile a standard C program. > > What exactly do you mean by a console application? I mean the kind of thing that Visual Studio creates if you select “Win32 Console Application” when you create a new C++ project. I.e., a program with the standard C interface to the operating system, i.e., an entry point called main. > There is a legacy console mode but it is very inconvenient to use. > Cutting and pasting in particular are not at all intuitive. Why exactly do > you want to use console mode? I didn’t say that it was what I wanted: it is all I would have expected (as in “I always expect pain when I upgrade my operating system”). I agree that cut and paste are clunky in command prompt windows, so it is great to have something nicer. > More generally, what exactly is it that you want to do that the present > version of Poly/ML will not let you do? This isn’t much of a problem for me, but what you are offering is rather inconvenient for anyone who wants to write ML programs that present the kind of interface that Windows command line programs like “sort" offer (with cmd.exe and the C runtime providing interactive input and output from a console window and redirection of standard input and output to files). Such things can be written portably using standard C or standard C++ and, it would be nice to be able to code similar things in ML without needing a wrapper to call them on Windows. > If you have an ML program that you want to run as a process with a separate > GUI application that is easy. Just create the input and output pipes and > pass them as arguments in the CreateProcess call. The ML process will be > completely invisible and all the user will see is your GUI. That's how I > normally run Poly/ML. > This is for the scenario where I write (in some other language) a GUI that is going to start my ML program and interact with it via files or pipes or suchlike. Is that right? > The only circumstance where the present system may not work satisfactorily is > if you have written a GUI application in ML itself, for instance the mlEdit > example in mlsource/extra/Win/Examples. How do you compile the code in that directory? It doesn’t seem to contain the source file for mlEdit that the documentation for the Windows interface refers to. > When the user double-clicks on the application to run it there would be an > extra window because the RTS creates its own GUI. > >> Cygwin does work for me, but unfortunately, having to install it is a >> stopper for some of my potential users. I tried compiling under MinGW >> with __CYGWIN__ set, but it doesn’t work. Would it be difficult to >> separate the choice between polystub.c being a standard C application >> and a Windows application from the __CYGWIN__ flag? > > Why does the user need to install Cygwin? If you build an application under > Cygwin you just need to put the Cygwin DLL and perhaps a few library DLLs in > the same folder as your application. Windows always searches for DLLs first > in the same folder as the executable. That might be an option, but it seems like quite an overhead to have to include something that provides vast amounts of functionality to emulate UNIX that I just don’t need and is a potential source of problems. So I was trying to explore the options for having libpolyml use standard C++ libraries (and not the Windows GUI libraries) without emulating UNIX. I am also thinking about the possibility of packaging an ML program as a Windows service (by providing my own libpolymain with entry points ServiceMain etc.) and thought that would be incompatible with the Windows GUI stuff, but maybe it will work with libpolyml compiled as it is presently or maybe it just doesn’t make sense. I will have to do some experiments. Regards, Rob.
_______________________________________________ polyml mailing list polyml@inf.ed.ac.uk http://lists.inf.ed.ac.uk/mailman/listinfo/polyml
