Comments on: Status: Stdio fixes and improvements

Here's a quick status update...

With major parse improvements implemented, please report any remaining bugs in CureCode so we can get them fixed. Please do not post reports for features that are not intended to be part of 3.0.0. (Minimize the noise on CureCode.) See the Parse Project wiki document, which you can edit if needed.

For the last few days the development focus is on fixing standard I/O (stdio), I/O redirection, proper UTF-8 for redirection, and the echo function. These may seem fairly simple, and it's not much code, but there are quite a few variations, all of which must be validated and tested.

Here's the list of what's involved...

lower level boot output (turned off in current builds)
boot crash notification (OS dependent)
higher level boot output (what you normally see)
lower level trace output
console prompt output
console input
PRINT function output
INPUT function input
system/port/output
system/port/input
echo output

Most of these are implemented, but the system/port changes are still pending.

I suppose I should also ask if you want stderr output. I'm not sure I see the need for it, and stderr can confuse the output stream. But perhaps you have a good reason for it?

Today effort is going into writing tests that will run on all platforms to validate that these work. Once stable, I'll post the tests (a script that builds all the tests, which are shell scripts themselves). I'll also be posting the R3 C code related to this. It's clean and easy to read.

8 Comments

Comments:

Kaj
26-Oct-2009 16:15:47 Cool, I'm eagerly awaiting first code. Sorry, but in a way C code still feels more like real, hardcore code than REBOL. :-)
These are important topics. I would like to have separate stderr support. It's expected in non-Windows environments, it's useful to separate it from general output, and when you want only one output stream those non-Windows environments make it easy to combine stdout and stderr.
-pekr-
26-Oct-2009 16:48 What to do about the console under Windows? On one hand, we want R3 to be launchable via an icon. But otoh, we want it to NOT launch its own console, in order to being able to use PowerShell or Console2 ( http://sourceforge.net/projects/console/ ) - that way we don't need to think about putting back R2 kind of console, and we can wait for VID3 based one :-)
Maxim Olivier-Adlhoch
27-Oct-2009 14:33:30 please allow separate stderr. it can be used by some monitoring apps to specifically log errors, while ignoring other user messages.
pixar also uses stderr and and stdout separately in its rendering queue engine in order to separate inter-node communications and actual node error/failure reports.
This, I guess, is a pattern used by other vendors and is an easy to use, simple multi-platform solution to a common scenario.
Brian Hawley
27-Oct-2009 21:24:44 Kaj, we want stderr on Windows too :)
Please test with Console2, as Pekr says. Also test with calling R3 from an existing console on Windows, to make sure the existing console is used and not another one. This will make integration with existing command line tools easier, as well as remote console support.
Kaj
28-Oct-2009 10:49:44 Did I say to leave out stderr on Windows? It's just not an original Windows feature.
Luke
29-Oct-2009 8:00:45 thankyou for fixing console/io!
I can now get CGI scripts to work on R3, so can start porting useful applications I have.
Luke
29-Oct-2009 8:02:14 I meant to say, I can get CGI now working on Windows - it hasn't worked up to now.
tomc
12-Nov-2009 5:41:03 please sir, can I have some more >&

Comments on: Status: Stdio fixes and improvements

Comments:

Post a Comment: