|
Anton
|
I think the reason for the "another process is running" error is that Crimson Editor launched a rebol process earlier which died as a result of some error. Since it was probably launched as cgi it does not open a console window, so you can't see it anywhere. It's a zombie. You must go to the task manager, find the rebol process and kill it.
I haven't tried using command launching features from a text editor for years, because I usually work straight from the console. I, too, was once enticed by the idea of integrating everything into one environment, but: - Errors such as you have experienced above don't allow you to diagnose what went wrong and when it happened, and are annoying to clean up. - It takes some effort to set up the editor to do this. Ok, it's a tiny effort, but all these little config steps add up, and you may have to do this every time you want to move to a newer version of rebol.
My rebol console and text-editor are decoupled. I can change text editor or rebol version and there is less setting up to do in order to get back to my usual way of working. What I do is set up a start menu item to launch rebol (I have various versions of rebol in a submenu, actually), so I can quickly launch rebol at any time with the system-wide, always-available key sequence "Ctrl+Esc down right Enter".
My way of thinking about it is the other way around - the console is the main application for me, and the editor is a slave application to it ! I've set up my user.r to define an EDIT function which launches Crimson Editor to open a script, and some file-system functions CD and LS for navigating the file-system, so my usual work-flow goes like this:
"Ctrl-Esc down right down Enter" (opens the newest rebol/view console) >> cd local/gui ; (change directory to %local/gui/) >> ls ; (list directory contents) >> edit %demo-scroll-panel.r ; (opens Crimson Editor) >> do %demo-scroll-panel.r ; test
I use arrow keys to access the console history and quickly redo previously typed lines. If anything went wrong, the console is still open so I can investigate the state of things directly. Finally, when I feel this console session is too "poisoned" by accumulated script errors and loose words and so on, I quit the console quickly with >> q
and restart, repeating the steps above, to test the script with a fresh console.
I hope that can be useful. I'm also interested in how other people stream-line their workflow patterns.
|