The Factor UI runs by default if it can:
Factor.app or run open Factor.app in a Terminal to start the UI; run ./factor in the Terminal to start a command-line listenerfactor.exe, or run .\factor.com in a command prompt, to start the Factor UI./factor in a shell to start the Factor UI if $DISPLAY is set. If $DISPLAY is not set, this will start a command line listenerTo start a command-line listener on Windows or Unix, pass -run=listener to the VM. For more information about command line switches, see http://docs.factorcode.org/content/article-command-line.html.
On Windows, factor.exe is the preferred executable to use when launching Factor from Windows Explorer, whereas factor.com should be used from the command prompt.
Running factor.exe from the command prompt will suppress standard input and output, and running factor.com from Windows Explorer will open a console window, even if the Factor UI is running.
On other platforms, the same Factor VM binary is able to be used in both command-line and graphical modes, but on Windows, whether or not a program can use the console is a property of the executable file itself, and not of the program's runtime. Two executables are needed; building solely as a console application is unacceptable, because even if a hack is added to the VM's main() function to hide the console as soon as the program starts in graphical mode, it would still flicker on the screen. There is no way around this with the Win32 API.
On Mac OS X, the factor binary at the top level of the source tree cannot run the Factor UI; it always runs the command-line listener. The Factor.app bundle runs the UI by default.
It is also possible to run Factor.app in command-line mode, by issuing the following in the Terminal, and this is in fact equivalent to running the VM using the factor binary at the top-level:
./Factor.app/Contents/MacOS/factor -run=listener
This revision created on Thu, 16 Jul 2015 07:51:04 by erg (fix link, thanks georg)