1. The Console
Since console access seems so slow in Win32, I decided to try wrapping the
functions and working with it directly. I'm not having much luck, so if
anyone can point out what I'm doing wrong here, I'd appreciate it.
The file is at:
http://www.lanset.com/dcuny/tmp/console.ew
When I run the program normally, nothing happens. When I run it in trace
mode, AllocConsole fails. My guess is that AllocConsole isn't typically
needed - Euphoria has already got a console.
The real problem is WriteConsole - I can't get it to write anything to the
console. I've also tried WriteConsoleOutputCharacter with similar
non-results.
Thanks!
-- David Cuny
2. Re: The Console
On 2 Nov 2000, at 10:44, Cuny, David@DSS wrote:
> Since console access seems so slow in Win32, I decided to try wrapping the
> functions and working with it directly. I'm not having much luck, so if anyone
> can point out what I'm doing wrong here, I'd appreciate it.
>
> The file is at:
>
> http://www.lanset.com/dcuny/tmp/console.ew
>
> When I run the program normally, nothing happens. When I run it in trace
> mode, AllocConsole fails. My guess is that AllocConsole isn't typically
> needed - Euphoria has already got a console.
>
> The real problem is WriteConsole - I can't get it to write anything to the
> console. I've also tried WriteConsoleOutputCharacter with similar non-results.
Just a thought... If Eu grabs a console for itself, for err displays, and you
try to use another one, would this be like trying to multitask dos?
Kat
3. Re: The Console
On Thu, 2 Nov 2000 10:44:00 -0800, Cuny, David@DSS wrote:
>Since console access seems so slow in Win32, I decided to try wrapping the
>functions and working with it directly. I'm not having much luck, so if
>anyone can point out what I'm doing wrong here, I'd appreciate it.
>
>The file is at:
>
> http://www.lanset.com/dcuny/tmp/console.ew
>
>When I run the program normally, nothing happens. When I run it in trace
>mode, AllocConsole fails. My guess is that AllocConsole isn't typically
>needed - Euphoria has already got a console.
>
>The real problem is WriteConsole - I can't get it to write anything to the
>console. I've also tried WriteConsoleOutputCharacter with similar
>non-results.
>
>Thanks!
>
>-- David Cuny
David,
It works fine on my Win2000 system. I included get.e and put a wait_key()
at the end so that the console wouldn't close but the console said "hello,
world!"... (I didn't use trace so you might be correct in your assumption
about the trace console.)
-- Brian
4. Re: The Console
Kat wrote:
> Just a thought... If Eu grabs a console for itself,
> for err displays, and you try to use another one,
> would this be like trying to multitask dos?
As far as I know, you only get one console per application. That's probably
why you get an error.
But even if you did, you still don't get multitasking - it's just another
window to read and write to.
-- David Cuny
5. Re: The Console
Brian Broker wrote:
> It works fine on my Win2000 system.
D'oh! Same here, now that I have it wait before shutting down.
Now to find out if it's faster than using printf. I suspect it isn't, but I
can hope!
Thanks!
-- David Cuny
6. Re: The Console
Dave:
If your main use is for printf, couldnt you simply wrap up a windows
based emulated console and direct your output there instead? I was
thinking of doing this myself recently, problem is, if it goes TOO fast
ill miss a lot of output anyway. Would like to speed up debugging
Euphoria programs though, that 'console' is so SLOW!!
Was also thinking of directing output to a file buffer also in order to
re-examine output after running a test program up to a certain point.
Let me know your thoughts on this.
Also was thinking of building a windows based debugger for Euphoria
that would take care of all that.
Take care,
--Al
7. Re: The Console
On 2 Nov 2000, at 11:45, Cuny, David@DSS wrote:
> Kat wrote:
>
> > Just a thought... If Eu grabs a console for itself,
> > for err displays, and you try to use another one,
> > would this be like trying to multitask dos?
>
> As far as I know, you only get one console per application. That's probably
> why you get an error.
>
> But even if you did, you still don't get multitasking - it's just another
> window to read and write to.
Then it is another instanciation of dos in wondoze?
Kat
8. Re: The Console
Kat wrote:
> Then [the console] is another instanciation
> of dos in wondoze?
I wouldn't go that far. I suspect it's more a 'virtual terminal' for
handling standard I/O. Even the Mac has a console window if you do C coding
without widgets (although in that case, it may be the responsibility of the
C library to implement the console).
-- David Cuny
9. Re: The Console
Al Getz wrote:
> If your main use is for printf, couldn't you
> simply wrap up a windows based emulated console
> and direct your output there instead?
If it were simple, yes. At some point I may do it. But for now, all I really
want to do is get the console writes to an acceptable speed.
> Would like to speed up debugging Euphoria
> programs though, that 'console' is so SLOW!!
If this is actually much faster, I'm sure that Robert would be more than
happy to fit it into Euphoria. It sure would make a lot of people happy -
running trace under Win32 is painful. But I *suspect* that Euphoria is
calling the same routines as I am, there's just more overhead (for example,
saving the screen before writing to it).
> Also was thinking of building a windows based
> debugger for Euphoria that would take care of
> all that.
How will you do that without having access to any hooks in the trace
routine?
-- David Cuny
10. Re: The Console
Bad news: Writing to the console through Win32 calls appears to be as slow
as through Euphoria.
*sigh* 
-- David Cuny
11. Re: The Console
> Since console access seems so slow in Win32, I decided to try wrapping
> the functions and working with it directly. I'm not having much luck,
> so if anyone can point out what I'm doing wrong here, I'd appreciate
> it.
>
Noticing the replys here, it looks like one might as well make a
Windows 'console' routine, opens a... 200x150 window and opens
binary I/O to it (printf()/get()?). (tho this can bring some trouble with
Eu trace, it'd probly havta clear the window before writing the next
screen? Could be slow?)
We sorta already have one, methinx, in one of the example progs..
Looks fast enuff to me. (Looks also like it could use some
optimization?)
my $.02.
--"LEVIATHAN"
12. Re: The Console
- Posted by David Cuny <dcuny at LANSET.COM>
Nov 02, 2000
-
Last edited Nov 03, 2000
LEVIATHAN wrote:
> Noticing the replys here, it looks
> like one might as well make a Windows
> 'console' routine, opens a... 200x150
> window and opens binary I/O to it ...
It may come to that. I wanted to avoid having to write the scrolling code,
etc. It also complicates wrapping Win32Lib.
Thanks for the feedback.
-- David Cuny
13. Re: The Console
- Posted by Derek Parnell <derekp at solace.com.au>
Nov 03, 2000
-
Last edited Nov 04, 2000
Hi David,
well now that the new release is out, I can try something new. So I knocked
up a console library this afternoon using Win32lib. It has the following
functions...
global procedure ConsoleOut(integer pConsole, sequence pText)
global procedure ConsoleRowCol(integer pConsole, integer pRow, integer pCol)
global function ConsoleOpen(sequence pTitle, integer pRows, integer pCols)
global procedure ConsoleClose(integer pConsole)
global function ConsoleMetrics(integer pConsole, sequence pMetric)
global procedure ConsoleColors(integer pConsole, atom pForeground, atom
pBackground)
It is just about ready for Alpha testing.
Currently I cannot get the background colors to change, no matter what I do.
Also the repainting is very brute-force like and this can be optimised. But
it does run very fast anyhow. Also, it is fixed at "Courier New, 10 point"
font for now.
It supports the standard console processing for Carriage Return, LineFeed,
BackSpace, Form Feed, and Tabstops. It scrolls up one line only if the
current character forces it to, which means you can safely write a character
in the bottom righthand corner with out the whole screen moving on you. It
supports consoles from 1 to 66 rows and 1 to 132 columns. You can have any
number of independent consoles open.
I'll post the code to the list later today, once my kids have gone to bed.
I plan to support the ANSI escape sequences, font changes, etc...
-----
cheers,
Derek Parnell
>-----Original Message-----
>From: Derek Parnell [mailto:dparnell at bigpond.net.au]
>Sent: Friday, November 03, 2000 6:38 PM
>To: derekp at solace.com.au
>Subject: Re: The Console
>
>
>LEVIATHAN wrote:
>
>> Noticing the replys here, it looks
>> like one might as well make a Windows
>> 'console' routine, opens a... 200x150
>> window and opens binary I/O to it ...
>
>It may come to that. I wanted to avoid having to write the scrolling code,
>etc. It also complicates wrapping Win32Lib.
>
>Thanks for the feedback.
>
>-- David Cuny
>
14. Re: The Console
On 3 Nov 2000, at 19:03, Derek Parnell wrote:
> Hi David,
> well now that the new release is out, I can try something new. So I knocked up
> a console library this afternoon using Win32lib. It has the following
> functions...
>
> global procedure ConsoleOut(integer pConsole, sequence pText)
> global procedure ConsoleRowCol(integer pConsole, integer pRow, integer pCol)
> global function ConsoleOpen(sequence pTitle, integer pRows, integer pCols)
> global procedure ConsoleClose(integer pConsole) global function
> ConsoleMetrics(integer pConsole, sequence pMetric) global procedure
> ConsoleColors(integer pConsole, atom pForeground, atom pBackground)
Kewl !
Kat
15. Re: The Console
Dave,
What i was talking about, the windows based debugger, in full form,
would require fully parsing the Euphoria source files, including
any include .e files that needed to be debugged. A simpler version
would require the user to specify the variables to be viewed during
the debugging process (not as nice but easier), but would still require
parsing into logical blocks at the very least, unless one could accept
the (rather harsh) restraint that each program be written with each
line containing exactly one logical block of Euphoria syntax:
constant a,b,c,d --would be acceptable
constant a,
b,
c,
d --would not be acceptable
Because of this restraint, i would opt for a full form debugger, but
again it would have to parse completely and accurately.
Color syntax would have to be similar to a text editor, if this
is really needed?
As with a debugger in any language, once the language is parsed,
it is a simple matter to insert calls to a display
routine/pause control procedure to print out variables and wait for
user input (such as step in, step through, etc.) as well as
correlate program blocks back to original line numbers.
It would be even possible to change variables during program execution.
Of course a new trace function would be introduced, say, "wintrace(1)".
Since you have been working on parsers recently, maybe you
feel up to producing a parser to parse the Euphoria language
into a group of logical blocks of text and variable names.
If so, i'll gladly produce the GUI portion, and we will
have ourselves a windows based debugger!
If i can, i'll post a simplified example debugger soon.
Let me know your thoughts on this...
--Al
