Windows console

classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|

Windows console

Nick.Trou
Has anyone written a nice Lua Windows console (as opposed to having to use
a DOS prompt) which they would be willing to post on here or point me to a
URL?

i.e. like the WinPython thing....

:-)

Ta,
Nick.



Reply | Threaded
Open this post in threaded view
|

Re: Windows console

Luiz Henrique de Figueiredo
>From [hidden email] Tue Jun 23 05:54:04 1998
>
>Has anyone written a nice Lua Windows console (as opposed to having to use
>a DOS prompt) which they would be willing to post on here or point me to a
>URL?

That would be a good thing to have. If anyone has it, please let me know and
I'll add a link to it the Lua site.

On the other hand, this should be provided by any compiler that claims to
be ANSI. Otherwise, how would it support stdio.h?
What do the current compilers do with stderr in Windows??

On the other hand, I've seen someone use the code below for putting
dialog boxes at error conditions.

#ifdef WIN32
    MessageBox(NULL,
               message, "Application Error",
               MB_ICONERROR | MB_OK);
#else /* has shell output */
    fputs(message, stderr);
#endif /* WIN32 */

--lhf

Reply | Threaded
Open this post in threaded view
|

RE: Windows console

Luc Van den Borre
In reply to this post by Nick.Trou
I register 'print_stack' as one of my own extension functions, and then do a luaL_check_string(1) to get the error from Lua, 
and print that out using a messagebox. This way you don't need to change the lua source code...

On 23 June 1998 12:04, Luiz Henrique de Figueiredo [SMTP:[hidden email]] wrote:
| >From [hidden email] Tue Jun 23 05:54:04 1998
| >
| >Has anyone written a nice Lua Windows console (as opposed to having to use
| >a DOS prompt) which they would be willing to post on here or point me to a
| >URL?
| 
| That would be a good thing to have. If anyone has it, please let me know and
| I'll add a link to it the Lua site.
| 
| On the other hand, this should be provided by any compiler that claims to
| be ANSI. Otherwise, how would it support stdio.h?
| What do the current compilers do with stderr in Windows??
| 
| On the other hand, I've seen someone use the code below for putting
| dialog boxes at error conditions.
| 
| #ifdef WIN32
|     MessageBox(NULL,
|                message, "Application Error",
|                MB_ICONERROR | MB_OK);
| #else /* has shell output */
|     fputs(message, stderr);
| #endif /* WIN32 */
| 
| --lhf

Reply | Threaded
Open this post in threaded view
|

Re: Windows console

Paul Bleisch-2
In reply to this post by Nick.Trou
Hi Nick,

I have one that is just about ready.  It is very basic.  You can drag-n-drop
files on it and it will do_file() them.  (Optionally resetting the environement
between files.)  There is a single input field for testing things.

As soon as I hook up a Lua print() facility to output to the console it
will be usable.  By default it builds against tklua (no GL) and the standard 
lua library.  

It is called WinLua or salt (stupid-ass-lua-tool).

Let me know if this will work for ya.

Paul


On Tue, Jun 23, 1998 at 05:53:51AM -0300, [hidden email] wrote:
> 
> Has anyone written a nice Lua Windows console (as opposed to having to use
> a DOS prompt) which they would be willing to post on here or point me to a
> URL?
> 
> i.e. like the WinPython thing....
> 
> :-)
> 
> Ta,
> Nick.
> 
> 
> 

Reply | Threaded
Open this post in threaded view
|

Re: Windows console

Paul Bleisch-2
I will make a pointer to this available as soon as I add the print
facility.

Paul

On Tue, Jun 23, 1998 at 12:53:00PM -0300, Paul Bleisch wrote:
> It is called WinLua or salt (stupid-ass-lua-tool).
> 
> Let me know if this will work for ya.
> 
> Paul
> 
> 
> On Tue, Jun 23, 1998 at 05:53:51AM -0300, [hidden email] wrote:
> > 
> > Has anyone written a nice Lua Windows console (as opposed to having to use
> > a DOS prompt) which they would be willing to post on here or point me to a
> > URL?
> > 
> > i.e. like the WinPython thing....
> > 
> > :-)
> > 
> > Ta,
> > Nick.
> > 
> > 
> > 
> 

Reply | Threaded
Open this post in threaded view
|

Re: Windows console

Luiz Henrique de Figueiredo
In reply to this post by Nick.Trou
>From [hidden email] Tue Jun 23 13:18:04 1998
>
>You have raised an interesting point there as well. Lua is designed as an
>embedded language but the way it outputs text is not very convenient for
>systems which can't trap the standard streams. ie. Windows (unless I'm
>missing something).

Lua is designed as an embedded language for ANSI C programs.
Any compiler that claims to support ANSI C *must* provide some implementation
the standard streams.
Think C on the Mac does this.
I don't know about Windows. Can someone please enlighten me here?

>You have to go through the Lua code and alter every
>printf, fprintf etc. to redirect the output to your buffer.

There are just a couple of such places:
	print in lbuiltin.c
	the standard error handler in ldo.c

Plus, you can always set your own error handler.

>What about having a function:  int lua_SendToOutput(FILE* stream, const
>char *pBuffer, ...);

I guess you can always write your own printf and fprintf and override the
compiler's implementation.

--lhf

Reply | Threaded
Open this post in threaded view
|

Re: Windows console

Nick.Trou
In reply to this post by Nick.Trou
Hi Paul,

That sounds great could you mail it to please: [hidden email]

You have raised an interesting point there as well. Lua is designed as an
embedded language but the way it outputs text is not very convenient for
systems which can't trap the standard streams. ie. Windows (unless I'm
missing something). You have to go through the Lua code and alter every
printf, fprintf etc. to redirect the output to your buffer.

What about having a function:  int lua_SendToOutput(FILE* stream, const
char *pBuffer, ...);

Then, all calls to printf in use this (ie. lua_SendToOutput(stdout,...) and
lua_SendToOutput(stderr, ...)). So, if you wanted to trap output you only
have to edit one function in lua to embed it properly in your code. And you
can grab the output of files if you want to check what they are writing....

I think this will work....?

printf("%d %d %d", 1,2,3);
becomes
lua_SendToOutput(stdout, "%d %d %d", 1,2,3);

fprintf(stderr, "%d %d %d", 1,2,3);
becomes
lua_SendToOutput(stderr, "%d %d %d", 1,2,3);

fprintf(myFile, "%d %d %d", 1,2,3);
becomes
lua_SendToOutput(myFile, "%d %d %d", 1,2,3);

void  lua_SendToOutput(FILE* stream, char *fmt, ...)
{
   char buff[500];
   va_list argp;
   va_start(argp, fmt);
   vsprintf(buff, fmt, argp);
   va_end(argp);

   // This is Lua's default call which I can now edit to redirect the
output
   // wherever I like.
   fprintf(stream, buff);
}

e.g. I could alter    fprintf(stream, buff); to
SendOutputToMyConsole("buff");
(This sends everything, including files, to my console window).

Nick.






Paul Bleisch <[hidden email]> on 23/06/98 03:53:15 PM

Please respond to [hidden email]

To:   Multiple recipients of list <[hidden email]>
cc:    (bcc: Nick Trout/UK/PSYGNOSIS)
Subject:  Re: Windows console





Hi Nick,

I have one that is just about ready.  It is very basic.  You can
drag-n-drop
files on it and it will do_file() them.  (Optionally resetting the
environement
between files.)  There is a single input field for testing things.

As soon as I hook up a Lua print() facility to output to the console it
will be usable.  By default it builds against tklua (no GL) and the
standard
lua library.

It is called WinLua or salt (stupid-ass-lua-tool).

Let me know if this will work for ya.

Paul


On Tue, Jun 23, 1998 at 05:53:51AM -0300, [hidden email] wrote:
>
> Has anyone written a nice Lua Windows console (as opposed to having to
use
> a DOS prompt) which they would be willing to post on here or point me to
a
> URL?
>
> i.e. like the WinPython thing....
>
> :-)
>
> Ta,
> Nick.
>
>
>







Reply | Threaded
Open this post in threaded view
|

Re: Windows console

Paul Bleisch-2
> You have raised an interesting point there as well. Lua is designed as an
> embedded language but the way it outputs text is not very convenient for
> systems which can't trap the standard streams. ie. Windows (unless I'm
> missing something). You have to go through the Lua code and alter every
> printf, fprintf etc. to redirect the output to your buffer.
>

The print facility I was talking about is done simply by registering a
C function in the lua environment (lua_OutPrint) and setting the global
'print' to point to the registered C function.  Although, I agree that
a central 'lua_Print' facility that is used *internally* by lua to print
stuff out would be groovy.

I also catch errors (and parse the passed in string to pull out the error 
information so I can print it out like I like).  

Please note that WinLua is very basic.  It was born because I was tired of
the command line tool.  So, it is pretty basic.  Umm... "a real handyman's
dream."

Paul
 

Reply | Threaded
Open this post in threaded view
|

Re: Windows console

Roberto Ierusalimschy
In reply to this post by Nick.Trou
> You have to go through the Lua code and alter every
> printf, fprintf etc. to redirect the output to your buffer.

As lhf noticed, there are only two places to change: "print" and the
error handler. You can always set your own error handler. Moreover, you
can redefine function print to print somewhere else (notice that the hard
work of "print" is done by tostring, so it is very easy to redefine print).
So, you need only a few lines of code to redirect Lua output to a message
window or to a file, all through the official API.

-- Roberto

Reply | Threaded
Open this post in threaded view
|

Re: Windows console

David Jeske-2
In reply to this post by Luiz Henrique de Figueiredo
On Tue, Jun 23, 1998 at 01:29:36PM -0300, Luiz Henrique de Figueiredo wrote:
> >From [hidden email] Tue Jun 23 13:18:04 1998
> >
> >You have raised an interesting point there as well. Lua is designed as an
> >embedded language but the way it outputs text is not very convenient for
> >systems which can't trap the standard streams. ie. Windows (unless I'm
> >missing something).
> 
> Lua is designed as an embedded language for ANSI C programs.
> Any compiler that claims to support ANSI C *must* provide some implementation
> the standard streams.
> Think C on the Mac does this.
> I don't know about Windows. Can someone please enlighten me here?

Right, but on windows it's basically impossible to get Lua's printf stuff
to redirect into your console without overriding _all_ printf
functionality. I can override the lua internal 'print()' function, but
that isn't everywhere that lua uses printf. 

In Lua 2.5 I just changed the internal lua print stuff to use a different
C function (dolua_print) so I could redefine where it goes. However, in
3.1 there are quite a few printf()s in the lua code, so I redirected _all_
printf()s by writing a new version of it. However, I would much prefer if
all lua print stuff went through a feeder api which could easily be mapped
to the standard funtions. For example:

Lua would never use:

  printf(...)
  fprintf(stderr,...)

Instead it would do something like:

  lua_printf(...)
  lua_fprintf(stderr,...

So I could easily trap and redirect these without affecting my programs
output facilities. If someone didn't want to redirect them, it would be
easy enough to provide standard implementations.,

> >You have to go through the Lua code and alter every
> >printf, fprintf etc. to redirect the output to your buffer.
> 
> There are just a couple of such places:
> 	print in lbuiltin.c
> 	the standard error handler in ldo.c

Even if it's going to remain this way I would prefer it if Lua would
enforce some concept of 'in the box' and 'out of the box'. Namely, put all
the 'absolute' output functions in one file, and make a convention in lua
not to use printf() or fprintf() outside that file. 

I agree completely with the original poster that as an embedded language
it isn't necessarily that useful for it to print to stdout.

> I guess you can always write your own printf and fprintf and override the
> compiler's implementation.

Yeah, and I do this, but it redefines _all_ my printf and fprintf usage,
so now I have to go around those functions when I really want to output to
the screen.

-- 
David Jeske (N9LCA) + http://www.chat.net/~jeske/ + [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Windows console

Paul Bleisch-2
> Instead it would do something like:
> 
>   lua_printf(...)
>   lua_fprintf(stderr,...

Just to nit.  lua_fprintf( stdout, ...) is just as good as lua_printf().  No?


And since we're on the subject of things that would make embedding Lua
easier.  I think Steve mentioned this earlier, but it would be extremely
useful to have the error handler take multiple parameters so it was not
necessary to parse the char *error string to get parse error information.

So instead of something like:  lua_error_handler( char *error ) I would
have lua_error_handler( int type, char *file, int line, char *last_token);

Paul 

Reply | Threaded
Open this post in threaded view
|

Re: Windows console

Nick.Trou
In reply to this post by Nick.Trou
>
>You have raised an interesting point there as well. Lua is designed as an
>embedded language but the way it outputs text is not very convenient for
>systems which can't trap the standard streams. ie. Windows (unless I'm
>missing something).

Lua is designed as an embedded language for ANSI C programs.
Any compiler that claims to support ANSI C *must* provide some
implementation
the standard streams.
Think C on the Mac does this.
I don't know about Windows. Can someone please enlighten me here?

>You have to go through the Lua code and alter every
>printf, fprintf etc. to redirect the output to your buffer.

There are just a couple of such places:
     print in lbuiltin.c
     the standard error handler in ldo.c

Plus, you can always set your own error handler.

>What about having a function:  int lua_SendToOutput(FILE* stream, const
>char *pBuffer, ...);

I guess you can always write your own printf and fprintf and override the
compiler's implementation.
---------------------------------------------------------------------------
-----

Does anyone know how to redirect the standard output streams into memory in
Windows (sorry I'm not an expert on this area of Windows)? You can use
freopen to redirect the standard streams into a file and then possibly
redirect this into a buffer but this seems like a bodge.

Surely if you trying to write ANSI code, you DONT want to be doing things
like redefining standard libraries (ie. printf)!

I still think it would be preferrable if Lua had text output wrapper. Don't
get me wrong, I think you have done a superb job with Lua. As embedded
languages go it is definitely the best I have found yet. It just seems like
a bit of a cludge to have to go through the Lua source (in each new
version!) and edit all the printf's as none of the rest of the source needs
modifying (apart from a few value number casts to avoid warnings!). If it
is to be a truly embedded language then I feel the client should have more
control over where the output goes. ANSI doesn't specify that all output
must go to the standard streams!

Nick



Reply | Threaded
Open this post in threaded view
|

Re: Windows console

Luiz Henrique de Figueiredo
In reply to this post by Nick.Trou
>From [hidden email] Wed Jun 24 06:11:39 1998

>Surely if you trying to write ANSI code, you DONT want to be doing things
>like redefining standard libraries (ie. printf)!

Exactly my point.
Any compiler that claims to support ANSI C *must* do something sensible
with printf and the like.
Some will do a bad job. In Windows, I think the nicest thing to do would be
to open a text console, with cut-and-paste and all -- not run the program
in DOS mode. Perhaps, this is an option in the compilers.

>a bit of a cludge to have to go through the Lua source (in each new
>version!) and edit all the printf's as none of the rest of the source needs

Like I said, "all the printf's" are *exactly* 2!
One is for a built-i function "print" (which you don't really need)
and the other is for lua_error, which you can trap.
So, I don't see any reason for changing the code at all!

>modifying (apart from a few value number casts to avoid warnings!).

I'd like to know what these warnings are. We take care to avoid all warnings.

>is to be a truly embedded language then I feel the client should have more
>control over where the output goes.
>ANSI doesn't specify that all output
>must go to the standard streams!

Right. That's why you can set your own error handler.
The rest of the output is in Lua's standard libraries and go explicitly to files.
The sample interpreter lua.c certainly assumes a text console, but I'd expect
that a much better one could be written for Windows. I just don't know how
to do it. C. Terra has written a very nice one for the Mac. There's a link
to it in our site.

To make my point again: The core of Lua does *not* output to stdout.
It can output to stderr in the default error handler.
The built-in function "print" outputs to stdout, but if you call it, you know
this. To output to files, use "write". To output to strings, redefine "write".

--lhf

Reply | Threaded
Open this post in threaded view
|

Re: Windows console

Luiz Henrique de Figueiredo
In reply to this post by Nick.Trou
There's an active discussiong about

	Should the C Programming Language be Amended to
	Provide for a Standard Console?    

going on in comp.lang.c.

--lhf

Reply | Threaded
Open this post in threaded view
|

Re: Windows console

Roberto Ierusalimschy
In reply to this post by Luiz Henrique de Figueiredo
  Just to make things clearer: below is a list of all "printf" inside Lua 3.1:


  lbuiltin.c:    printf("%s\t", svalue(L->stack.top-1));
  lbuiltin.c:  printf("\n");
  ldo.c:  fprintf(stderr, "lua error: %s\n", lua_getstring(lua_getparam(1)));
  ldo.c:    fprintf (stderr, "lua: exit(1). Unable to recover\n");
* liolib.c:    fprintf(stderr, "lua_debug> ");
* liolib.c:    fprintf(f, (level==2) ? "Active Stack:\n\t" : "\t");
* liolib.c:        fprintf(f, "function %s", name);
* liolib.c:        fprintf(f, "`%s' tag method", name);
* liolib.c:          fprintf(f, "main of %s", filename);
* liolib.c:          fprintf(f, "%s", filename);
* liolib.c:          fprintf(f, "function (%s:%d)", filename, linedefined);
* liolib.c:      fprintf(f, " at line %d", currentline);
* liolib.c:      fprintf(f, " [in file %s]", filename);
* liolib.c:    fprintf(f, "\n");
* liolib.c:  fprintf(stderr, "lua: %s\n", lua_getstring(lua_getparam(1)));
- lstate.c:  printf("total de blocos: %ld\n", numblocks);
- lstate.c:  printf("total de memoria: %ld\n", totalmem);
  ltm.c:    fprintf(stderr, "lua: %s\n", lua_getstring(o));
  ltm.c:    fprintf(stderr, "lua: unknown error\n");
+ lua.c:  fprintf(stderr,
+ lua.c:    fprintf(stderr, "lua: shell argument too long");
+ lua.c:      printf("%s", lua_getstring(lua_getglobal("_PROMPT")));
+ lua.c:        fprintf(stderr, "lua: argument line too long\n");
+ lua.c:  printf("\n");
+ lua.c:      printf("%s  %s\n", LUA_VERSION, LUA_COPYRIGHT);
+ lua.c:          printf("%s  %s\n(written by %s)\n\n",
+ lua.c:            fprintf(stderr, "lua: error running argument `%s'\n", argv[i]);
+ lua.c:          fprintf(stderr, "lua: cannot execute file ");

Those with * are part of the standard input/output library, which explicitly
uses streams. + is the stand-alone Lua, which needs a console. - is just for
debuging (the messages are in Portuguese ;-). (In fact, there are also a
few "getc", but again they only appear in the I/O library and the
stand-alone program.) That leave us with:

1 lbuiltin.c:    printf("%s\t", svalue(L->stack.top-1));
2 lbuiltin.c:  printf("\n");
3 ldo.c:  fprintf(stderr, "lua error: %s\n", lua_getstring(lua_getparam(1)));
4 ldo.c:    fprintf (stderr, "lua: exit(1). Unable to recover\n");
5 ltm.c:    fprintf(stderr, "lua: %s\n", lua_getstring(o));
6 ltm.c:    fprintf(stderr, "lua: unknown error\n");

Lines 1/2 are the implementation of "print"; just redefine "print" to avoid
them. Lines 5/6 is the old implementation of the default error fallback, and 
line 3 is the current implementation of the default error handler; just
redefine the error handler to avoid them. That leave us with only line 4.
This is the only place in the core of Lua where you cannot avoid the use of
stderr, but this is an emergency exit (it is followed by an "exit"!). This
only happens if a Lua error occurs in a point when there is no point to
recover; that is, outside any dofile, dostring, or lua_call. It can only
happen in C, and independently of printf problems, you should always avoid
the chance of such errors.

  People here at PUC have been using Lua with Windows since its first version,
and this redefinition of "print" and the error handler have done the job,
so far. But maybe we are missing something.

  Anyway, we are afraid we won't be able to make any changes to 3.1. As lhf
said, it is practically ready (it is already frozen in the RCS, we are just
making some final tests in different platforms and building the "tar"), and
unless a real bug appears we will not change this version. But we can make
the change in the next version.

-- Roberto

Reply | Threaded
Open this post in threaded view
|

Re: Windows console

Nick.Trou
In reply to this post by Nick.Trou
> > modifying (apart from a few value number casts to avoid warnings!).

> I'd like to know what these warnings are. We take care to avoid all
warnings.

In the lua code where value.number is set from an int and not cast and in
the maths library where value.number floats are set as doubles.

Be nice if you had a typedef int/float/double valueNumberType so you could
set the lua value number type and cast everything properly.

Nick


Reply | Threaded
Open this post in threaded view
|

Long file names in Lua

Steve Dekorte-2
In reply to this post by Roberto Ierusalimschy
Lua can't seem to handle long file names for dofile().

Has anyone else run into this problem?

Steve