On 2012-04-09, at 12:59 PM, REPLeffect wrote:
On Mon, Apr 9, 2012 at 9:16 AM, Marc Feeley feeley@iro.umontreal.ca wrote:
On 2012-04-09, at 9:44 AM, REPLeffect wrote:
So I'm wondering -- has Gambit ever been tested to work without the console window? I know you can hide it when calling the process-related procedures, but I couldn't find anything in the documentation or on the mailing list about the main app not having a console.
It is clearly possible, for example the Jedi IDE for JazzScheme is a window application written with Gambit. Perhaps looking at the Jedi sources will give you some ideas.
Also, here's an old message to the Gambit ML which seems related :
https://mercure.iro.umontreal.ca/pipermail/gambit-list/2011-March/004939.htm...
Finally, I sent a private message on this subject which I should have CC'd to the Gambit ML. It is copied below.
Let me know if you need more assistance.
Marc
[snip]
Thank you, Marc. That was very helpful. Turns out, I was not defining ___LIBRARY while compiling one of my scheme modules, nor when compiling at least one of the link files I was generating.
After adding the ___LIBRARY define, the application ran fine when compiled as a non-console windows app. I even checked the portable executable header of the executable to confirm that it was using the "windows" subsystem (as opposed to "console") -- which it was.
The only thing that puzzled me, was that I was still getting a terminal window popping up with my debug messages printed to standard output. On a hunch, I ran the executable and piped stdout to an output file. When I did this, no console window popped up, and the application ran as expected.
So my question is this -- If a Windows app with Gambit embedded does not have a console, does the runtime open a new one (using CreateProcesss, I'm assuming) in order to display data sent to stdout? And if so, are there any setup parameters I can change to prevent this? Ideally I'd like to be able to turn this on and off at will, or at least be able to chose one way or another at startup. For debugging purposes, it is handy to have the console, but for my users I'd want to shut it off.
On Windows, the console is actually created by a call to AllocConsole in lib/os_tty.c (on Unix, the "controlling terminal" is opened). This is done lazily upon the first output (or input) to the "console port" (which is the port returned by the procedure console-port). The console port is the port normally attached to the REPL channel. So the console will pop up when an error message needs to be output, or when pp is called (with no explicit port argument), or when a REPL is started for any of many reasons.
The REPL channel's port can be changed by adding the -:d- runtime option when the program is started. This will assign the standard input/output to the REPL channel. For example :
% gsi -e "(/ 1 0)" > out *** ERROR IN (string)@1.1 -- Divide by zero (/ 1 0) % cat out % gsi -:d- -e "(/ 1 0)" > out % cat out *** ERROR IN (string)@1.1 -- Divide by zero (/ 1 0)
Moreover, by adding a 0 to the runtime debug options, the display of the error message will be supressed:
% gsi -:d0- -e "(/ 1 0)" % echo $? 70 % gsi -:d- -e "(/ 1 0)" *** ERROR IN (string)@1.1 -- Divide by zero (/ 1 0)
Note also that you can write a script whose first line contains the runtime options. For example, on Unix:
-------------------------------------------- #! /usr/bin/gsi -:d0- (pp (/ 1 0)) --------------------------------------------
or on Windows:
-------------------------------------------- @; gsi.exe -:d0- (pp (/ 1 0)) --------------------------------------------
Finally, note that the runtime options on the first line of a script that is compiled by gsc become the *default* runtime options when they are not specified explicitly to the executable.
This is probably what you should do to avoid creating a console window.
You might want to read the "Compiling scripts" section of the Gambit manual.
Marc