Re: [boost] Is there interest in a reusable stream-based console?
@Julien: I haven't looked into boost::program_options yet, though I don't see a problem in integrating the current design in anything as it's merely a class that reads from a std::basic_istream and writes to a std::basic_ostream whilst calling registered callbacks based on the input… The parameters are currently instances of std::basic_string which are passed to the callback which can than operate on these parameters. On the list of commands thing: I thought about that for a while now and would say that something like Lua would be a perfect solution to be combined with the current design to allow that flexible scripting… @Artyom: I've never before heard about GNU Readline; does that mean that consoles like bash don't offer such a functionality to programs automatically (something that even cmd.exe does)? "Help" is meant to be a short help text on the command, similar to a man-page…
On Sat, Mar 10, 2012 at 12:26 AM, Michael Hava <mfh@live.at> wrote:
@Julien: I haven't looked into boost::program_options yet, though I don't see a problem in integrating the current design in anything as it's merely a class that reads from a std::basic_istream and writes to a std::basic_ostream whilst calling registered callbacks based on the input…
The parameters are currently instances of std::basic_string which are passed to the callback which can than operate on these parameters.
On the list of commands thing: I thought about that for a while now and would say that something like Lua would be a perfect solution to be combined with the current design to allow that flexible scripting…
@Artyom: I've never before heard about GNU Readline; does that mean that consoles like bash don't offer such a functionality to programs automatically (something that even cmd.exe does)?
"Help" is meant to be a short help text on the command, similar to a man-page…
______________________________**_________________ Unsubscribe & other changes: http://lists.boost.org/** mailman/listinfo.cgi/boost<http://lists.boost.org/mailman/listinfo.cgi/boost>
Functionality like command history, autocomplete, etc should be a part of the library, you can't just assume that it exists. For example, I wrote a DirectX 'overlay' a while ago which I added a console to for debugging purposes. Because this had to be implemented as part of the overlay it needed to be written from scratch. If you want your library to be usable in a wide variety of scenarios then you can't just assume that functionality exists, because it often doesn't. Someone has to write that code. ;) I am interested in your library and seeing it become a part of Boost, however I agree that history, search, auto-complete, etc being integrated into the library would be key to making it a more useful addition. Do you have Git/SVN/etc repo up somewhere so people can check out the current progress? Thanks.
Hello, I'm interested too. I'd like to share my short experience in the domain. I've implemented a command line system before that I, too, use in video games implementations. The one I wrote at the time might have big design flaws, but at least it was easy to set custom outputs. (example: http://www.youtube.com/watch?v=VHFu6q1twtE ) The design was basically: - some functions insert inputs (taking characters or strings, manipulating the cursor position) - some virtual pure functions to implement the output rendering: in the video, it generate a javascript expression, send it to an embedded browser that will display on the 3D texture you see flying - that is in fact a web page. It is the third output rendering I've wrote using the same console base class, the first was simply standard output, the second was raw font rendering on some 3D textures (but it was slower than the 3rd solution). - some functions to add/remove "commands" that are the "applications" available to the console instance (I use several different consoles, like in the video) - a special mode that allow a command to be "modal"(I can't find a better term), meaning that the command will keep getting the inputs until it shut down, without having to loop inside the command code - to allow rendering to still happen. Having an implementation better designed and reviewed by boost people might be more reliable than my current code (that I already tagged as to be refactored - this version is opensourced online but I don't think it's good enough to check it). About the swig/boost.python thing, one thing to understand is that command line don't work like a programming language. You don't use it for the same purpose, even if it's tempting to just let a scripting language as the implementation of the console. For example you might not want command line to be able to create/destroy objects. If you do, it's far better to plug your scripting language inside your console as a command/application like I did. It's far more extensible this way. In the video, I used Falcon (http://falconpl.org) as a scripting language. I could have used any other language (Lua, Python, ChaiScript) without changing the console class. I could also have added several other scripting language, as they are only commands/applcations from the console point of view. I plan to have different consoles for different contexts in my current game, and different commands to manipulate different scripting language VMs. So I don't think it's a good idea to plug directly a specific language inside a console. About the interface, I'm not sure if a command should be defined only by a simple std::function. I've tried it before but I wasn't able to make it work as more information were required. My 2 cents. Joël Lamotte
About the swig/boost.python thing, one thing to understand is that command line don't work like a programming language. You don't use it for the same purpose, even if it's tempting to just let a scripting language as the implementation of the console.
They don't?! You need a better command line. :P Fair enough, I probably wouldn't want to give someone a full Python interpreter inside a video game. Still, I suspect locking down a full interpreter is easier than inventing, implementing, and fully testing a one-off language with reduced capabilities. Especially because the capabilities will likely need to grow in time as your users become more advanced. It's nice to one day say "Oh yeah, that's actually Python" rather than say, "Oh yeah, we need to re-invent something functionally equivalent to Python but which is expressed in our in-house language." - Rhys
On Fri, Mar 9, 2012 at 16:58, Rhys Ulerich <rhys.ulerich@gmail.com> wrote:
Fair enough, I probably wouldn't want to give someone a full Python interpreter inside a video game. Still, I suspect locking down a full interpreter is easier than inventing, implementing, and fully testing a one-off language with reduced capabilities.
It depends on the context. In mine, I want to provide a full scripting language VM to the game developer. I also want (and that is "rare") to let the user play with another VM that have a specific purpose (and is allowed only some libraries of the scripting language). It IS useful to be able to use a scripting language in a command line system (whatever the purpose - I have several different ones but I'm in a very special case I think). But it is non-sense to make a scripting language be the command line system implementation.
Especially because the capabilities will likely need to grow in time as your users become more advanced. It's nice to one day say "Oh yeah, that's actually Python" rather than say, "Oh yeah, we need to re-invent something functionally equivalent to Python but which is expressed in our in-house language."
Then just provide a command that is "modal" and called (from the code) at the beginning of the console. It would only send expressions to the scripting language VM and return it's result. Make sure the VM is loaded with the wanted libraries and other tools that the user might need. Don't bother the console system, it should only be an "interface", nothing more. That is, in my experience, the way to get it modular enough to make it useful to a lot of people. Joël Lamotte
Michael Hava <mfh@live.at> writes:
I've never before heard about GNU Readline; does that mean that consoles like bash don't offer such a functionality to programs automatically (something that even cmd.exe does)?
Remember that 'bash' isn't a "console": it's a shell, which is really just another program that has a standard input, a standard output, and a standard error. Unix evolved a very clean separation of responsibilities regarding terminal devices: 1. raw tty - character input/output 2. line discipline - xon/xoff, crlf handling, etc 3. application In the case of a shell like 'bash', it's bash that provides command line editing and history -- but once another program has been invoked, that other program is fully responsible for all application-level editing, history, rendering, etc. The readline library (and a few others that have sprung up due to the fact that readline is GPL'd) can be linked to any application (bash, gplot, whatever) to provide for history, editing, completion, etc. I'm using the BSD EditLine library ("libedit") in my application right now, and it's working quite well. In contrast, the command.com / cmd.exe environments are a bit of a mishmash, and while they might provide the history services to programs you run on the command line, I don't know if they make it possible for each command to keep its own history, provide its own completions, etc. (Command.com and cmd.exe also fail to provide other features that unix programmers take for granted, e.g., filename wildcard / globbing.) Finally, remember that Unix "grew up" dealing with many different terminal output devices; the earliest didn't have screens at all, let alone the ability to move a cursor backwards and replace existing text. After that, there was a period when there were a large variety of different serial terminals, each with their own commands to position cursor, change color, etc. This begat another abstraction layer (curses, terminfo, etc). The combination of that last layer, however, together with the tty / line discipline / application stack described above, allows the exact same application to run over network login sessions (telnet, rlogin), secure sessions (ssh), usb serial, and regular serial. Cmd.exe fails in almost all of those situations, which is why "remote administration" of a windows server usually means "remote graphical desktop"... In short, you can't rely only on experiences with cmd.exe.
participants (5)
-
Anthony Foiani -
Joshua Boyce -
Klaim - Joël Lamotte -
Michael Hava -
Rhys Ulerich