Archived messages from: gitter.im/red/CLI from year: 2021

greggirwin
19:27We are going to push forward with @hiiamboris' [CLI](https://gitlab.com/hiiamboris/red-cli) work and make it standard in Red. It's quite a different approach than I used in my work for Rebol, and it took me a little time to adjust, but it's quite idiomatic and powerful. It's an important module, and will be widely used. So, first, thanks to @hiiamboris for his work and defending it when I said "I don't get it."

I'm planning to do a fresh review of it, but would like at least two other people to do so as well. He has a lot of examples to work from, but creating more is always good. On the review side, we need both high level (interface) feedback, and also at least one internal code review. Don't do the code review yet though, because CLI will be a Q1 2022 roadmap item, and HOFs will come first. Once HOFs are in Red, it's likely that CLI will use them internally. As always, though, I will press for clear and simple code.
19:31I've chatted a bit with Boris about interrogative interfaces, and how I see them applying to CLI, APIs, messaging systems, and more. The idea being that you may send a request or partial command, and what you get back (in a REST-like manner) is more information about what you can do next or detailed help for command parameters. In CLIs, my canonical example is fsUtil on Windows. Boris' CLI has sub-command support built in, which makes organizing rich CLIs really easy.
19:35We're having a lot of chat on split right now as well, and how to evaluate designs (evidence oriented language design). For CLI the starting point is process-into and having more people (you) try it and provide feedback.
GalenIvanov
21:24I might try to make a CLI version of TruTiles
greggirwin
21:31That would be a great use case, given all the options it has.
21:32@toomasv, it will also be good to pursue the idea of using it in DiaGrammar, as we discussed some time back.

rebolek
07:58CLI is very interesting to me, I live in console more than in GUI, so I definitely will take a deep look at it.
greggirwin
18:17:+1:

GalenIvanov
10:24I made a [CLI-version of TruTiles](https://github.com/GalenIvanov/Graphics-Red/blob/master/TruTiles-CLI.red)
10:24
Syntax: TruTiles-CLI [options] <rule>

Options:
                    <rule>        Type of tiling to be used - one of r3, r4, 
                                  r6, r6-3, r6-3-3, r6-4-3, r8-4, r12-3, 
                                  r12-6-4, r4-3 or r4-3a
      --size        <cell-size>   Size of the cell, between 15 and 250. 
                                  Default: 40 pixels
      --rotate      <rotation>    Rotation angle. Default: 0 degrees
      --width       <cell-line>   Line width. Default: 3 pixels
      --color       <edge-clr>    Cell edge color. Default: sky
      --bg-color    <bg-clr>      Backgraound color. Default: aqua
      --shadow                    Turn on shadow. Default: off
      --sh-color    <shadow-clr>  Shadow color. Default: black
      --sh-line     <shadow-size> Shadow line width. Default: 9 pixels
      --sh-offset   <shadow-offs> Shadow offset. Default: 0x0
      --tile-mix    <ratio>       Share of each effect in the image: Tile, 
                                  Dual, Diamond, Truchet, Diagonal. Default: 
                                  100.0.0.0.0
      --seed        <rand-seed>   Random seed. Default: 0
  -o                <output>      Output file name. Default: TruTiles.png
  -v                              Display result in a window
      --version                   Display program version and exit
  -h, --help                      Display this help text and exit
toomasv
10:27:+1:
hiiamboris
10:39Good job, and clever usage of tuples. Which opens up a question if we should support them as CLI argument type.
10:43We do not because most of the world has no idea about Red datatypes.
10:43But if we target Reducers with our tools it starts making sense.
rebolek
10:44They should be strandartized as ISO 16711680.
hiiamboris
rebolek
10:45ISO 3840 is taken I guess.
hiiamboris
10:45These are not just random numbers?
rebolek
10:45No :)
loziniak
10:46https://calculator.name/baseconvert/decimal/hexadecimal/16711680
hiiamboris
10:46haha
GalenIvanov
11:15Thanks guys! Although my test was a very basic one, I find @hiiamboris' [CLI](https://gitlab.com/hiiamboris/red-cli) really powerful and easy to use. I hope it will be embeded into Red.
greggirwin
19:44Agreed on the clever use of tuple for the mix value @GalenIvanov.

Is there any downside to supporting tuples, or any other Red type? For those who don't want conversions, just don't specify a typeset.
hiiamboris
19:50Tuples lead to support of words, and words lead to their charsets not being defined. Then you build your program with different Red versions and may get previously accepted words to now report an error or vice versa.
Not the end of the world but somewhat shaky ground.
greggirwin
19:50TruTiles shows how easy this can be. It leads to another piece of the puzzle, with CLI tying to app architecture, configs, and hierarchical environments.
19:53@hiiamboris that's a general compatibility issue, isn't it? I also don't see how tuples tie to words. What's the dependency?
hiiamboris
19:54Dependency is, we added first Red type (unknown to outsiders) into the mix, why don't we add them all. Words are next candidate simply. Used by Galen extensively, and I think I've used them myself. Or though of using instead of strings. Somewhere.
greggirwin
20:17You already have issue! in there, which is a word type. But the compatibility issue comes down to specifications. As hard as it will be to nail those down, we need to. Because Red is data, we don't want to break it once it we do that. That's true for all types.

If we limit the types, based on the rest of the world, we lose a lot of potential value and leverage. For example, you can pass CLI args directly, but once they get larger, or may contain line breaks, can there be a standard switch to say "get the args from a file"? Why not? And if we can do that, why wouldn't we want that to be fully loadable Red?
20:18It's just that standard POSIX CLI syntax is foreign to us, requiring processing.
hiiamboris
20:24So you're for more types support.
greggirwin
20:24Internally, CLI args map to a data structure of operands and options. There are some limitations in place, like options having only a single arg. Back to configs, that's what the CLI maps to, with the config being the func spec. It could also map directly to a config object. The CLI is just the last thing in the stack of environments that overrides everything else.
20:26> So you're for more types support.

Clearly :^) But I do want us to find the biggest problems they cause and then we can decide if they are so horrible that they must be disallowed, or if knowing about the risks is enough.
hiiamboris
20:28No objects. I'm just being conservative here. Allowing later is always easier than forbidding what we previously allowed.
greggirwin
20:29I just checked and it looks like I started to dust off my old rebol %config-lib.r in the split repo, but not enough to commit it.
20:29Agreed on extending later. Until we have serialized syntax, they're a pain. After we do, they'll just be ugly. :^)
hiiamboris
20:35I would not want serialized values there at all. Especially any-functions.

greggirwin
21:41I need to review CLI again soon, but we got a thumbs-up from Nenad to move forward with it. :+1:

hiiamboris
07:00Yoohoo.