Wiki Updates (masochism?)

[Grotfang]

One way to get nice search behavior is to have a lot of redirects. Another is to name pages with titles more likely to be searched for, saving someone the work of making a bunch of redirects.

I suppose that's my point. I didn't consciously make a redirect. I was wondering what I did to make it redirect and why that couldn't be standard.

 

[lostcalpolydude]

I suppose that's my point. I didn't consciously make a redirect. I was wondering what I did to make it redirect and why that couldn't be standard.

zarqon made the redirect before you made the page it redirected to, based on looking at page histories.

 

[CptJesus]

So wait, whats the consensus? Or is there even one yet? I would love to get my hands dirty editing what I know of the wiki.

 

[aqualectrix]

zarqon made the redirect before you made the page it redirected to, based on looking at page histories.

Wait, I knew zarqon was pretty darn awesome, but he can see the future too?

Someday, I imagine him thinking to himself (in italics, of course), someone will create the item_amount() page, and I will want to find it by searching for "item amount". Better make the redirect now!

That's it. I will now be disappointed when his scripts don't support new skills and items out-of-the-box, because if he can see the future he ought to be able to incorporate them even before they roll out in KoL...

 

[zarqon]

I want to give massive encouragement to whomever wants to work on the ASH Wiki. So, yes, yes, and yes!

I think the parentheses are necessary -- especially should CLI commands later be added, which I think would be nice, since many ASH functions have a CLI equivalent and vice versa. Parenthese-less redirects could certainly be added for ASH functions without CLI equivalents.

A couple comments about the function template:

When I overhauled the "My Character" category a while back I tried to include each function's default return value (return value when logged out).

A "see also" section would be nice (I'm thinking of the PHP online documentation here).

It may also be nice to describe whether or not (or under what conditions) calling the function hits the server, since that seems to be an issue of confusion for many new scripters. Some have needlessly stored function return values in variables to avoid repeatedly calling the function under the mistaken assumption that the function generated a server hit.

 

[lostcalpolydude]

I think the parentheses are necessary -- especially should CLI commands later be added, which I think would be nice, since many ASH functions have a CLI equivalent and vice versa. Parenthese-less redirects could certainly be added for ASH functions without CLI equivalents.

The command name is normally a bit different, from what I can tell. For the few cases where they're actually the same, disambiguation pages could be used.

 

[bumcheekcity]

Absolutely agree with Zarqon here, the () are necessary for ASH functions, and should be kept in. As per Doodle's request, and the fact that we can't use conditionals in our templates until the website is edited, we should discuss the templates here as not to overwrite them.

 

[CptJesus]

Might I suggest we discuss this on the IRC channel I just set up at some point in the near future? =P It might be easier to get all the opinions in a constant flow instead of one at a time.

It would give me a chance to test out my channel and make sure everything is working too.

 

[fewyn]

I'll be upgrading the wiki and adding parser functions tomorrow.

 

[StDoodle]

I think the parentheses are necessary...I'm thinking of the PHP online documentation here...

Ok, that may have been mashed together out-of-context, but still. If you're thinking of pages such as THIS then I'd have to disagree with parenthesis being part of the page name.

I do, however, fully support the idea of adding in something for "See also" functionality into the ash function page template(s).

Absolutely agree with Zarqon here, the () are necessary for ASH functions, and should be kept in.

I'm going to take one last stab at it and mention that the parentheses are a language construct, not part of the function name itself. However, in the interest of Mercedes McNab*, we should probably vote on it and come up with a standard way of dealing with this.

If we go with functions w/o (), we would need disambiguation pages every time the same names is used for a cli command.

If we go with functions w/ (), we need to either 1) Pipe all links (easy to miss, and has the downside of searches not directly leading to function pages) or 2) Create a redirect for every single function that doesn't have a cli equivalent. In the case of #2, we still need to decide whether searching for, say, "drink" should take you directly to the cli command page, possibly with a "Did you mean..." for the ash function, or if disambiguation pages should be used.

As per Doodle's request, and the fact that we can't use conditionals in our templates until the website is edited, we should discuss the templates here as not to overwrite them.

Since the conditional situation is about to change, we'll have a much easier time coming up with flexible templates. However, I think that makes it even more important that we hammer out what exactly they should include before we go ahead and start overhauling things.

For the few cases where they're actually the same, disambiguation pages could be used.

This is my thinking as well, as per above. (As in, even with parentheses as part of function names, they may still be required.)

I'll be upgrading the wiki and adding parser functions tomorrow.

Woot, thanks fewyn, that will make a lot of the complicated, flexibility-minded pre-planning stuff much more feasible!

I want to mention that:

1) I am not a programmer by trade. In some instances, this means I won't agree completely with the approach that others have. I don't think this is always a bad thing for this project, though, as I'd really like to open up ash to others, like myself, who aren't really programmers by nature. I tend to approach this project more from the perspective of "how can we be of most help to a complete ash noob" than "how can we provide professional documentation just like other languages have." However, I do understand that each trade has its list of things that "must be done a certain way." I don't want to stomp all over standards; I just want to make things easier for new scripters. Please keep that in mind.

2) The overall goal here is not just to revamp the entire kolmafia wiki overnight. That's a task beyond us at the moment. I'd love to make a great deal of progress, but there's a strong possibility that in a few days, I will no longer have the free time to put towards a great deal of editing. I would much rather we came up with a solid foundation of templates and standards, so that anyone who looked into it knew exactly what to do, and how, when going to re-write a function page. I'd like to make it incredibly easy for a casual wiki user to go through and edit pages in a standardized way as they see fit. Right now, the pages are a hodge-podge of standards and philosophies, and there's very little coherence to the wiki as a whole.

With all of this in mind, I think it's best, going forward, if we decide on what templates are needed and what information should be standard in those templates. As for the actually syntax of those templates, let's not worry about that at the moment. It looks like at least myself & bumcheekcity have a clear enough idea on wiki template syntax to come up with workable templates, once we're sure what to put in them. That's where I'd like to concentrate efforts in the planning stages.

One thing for sure I want to avoid is pages like THIS.

Edit to add footnote: *Mercades McNab is the name of an actress from Buffy: The Vampire Slayer and Angel who played a character named "Harmony." It's a dork-joke.

 

[bumcheekcity]

I'm going to take one last stab at it and mention that the parentheses are a language construct, not part of the function name itself. However, in the interest of Mercedes McNab*, we should probably vote on it and come up with a standard way of dealing with this.

If we go with functions w/o (), we would need disambiguation pages every time the same names is used for a cli command.

If we go with functions w/ (), we need to either 1) Pipe all links (easy to miss, and has the downside of searches not directly leading to function pages) or 2) Create a redirect for every single function that doesn't have a cli equivalent. In the case of #2, we still need to decide whether searching for, say, "drink" should take you directly to the cli command page, possibly with a "Did you mean..." for the ash function, or if disambiguation pages should be used.

Actually, you've won me over with the reminder of the piped links.

The function template can take account of the fact that it may be an ASH or CLI function within the template. In which case it certainly needs to be of the form:

{{#if: cli | '''[[{{{returns}}}]]''' '''{{{name}}}'''

{{#if: p1 | ''{{{p1t}}}'' {{{p1}}} }}
{{#if: p2 | , ''{{{p2t}}}'' {{{p2}}} }}
{{#if: p3 | , ''{{{p3t}}}'' {{{p3}}} }}
{{#if: p4 | , ''{{{p4t}}}'' {{{p4}}} }}
{{#if: p5 | , ''{{{p5t}}}'' {{{p5}}} }}

}}
{{#if: ash | '''[[{{{returns}}}]]''' '''{{{name}}}(

{{#if: p1 | ''{{{p1t}}}'' {{{p1}}} }}
{{#if: p2 | , ''{{{p2t}}}'' {{{p2}}} }}
{{#if: p3 | , ''{{{p3t}}}'' {{{p3}}} }}
{{#if: p4 | , ''{{{p4t}}}'' {{{p4}}} }}
{{#if: p5 | , ''{{{p5t}}}'' {{{p5}}} }}

)''' }}
{{#if: p1 | '''{{{p1t}}}''' {{{p1}}} - {{{p1d}}} }}
{{#if: p2 | '''{{{p2t}}}''' {{{p2}}} - {{{p2d}}} }}
{{#if: p3 | '''{{{p3t}}}''' {{{p3}}} - {{{p3d}}} }}
{{#if: p4 | '''{{{p4t}}}''' {{{p4}}} - {{{p4d}}} }}
{{#if: p5 | '''{{{p5t}}}''' {{{p5}}} - {{{p5d}}} }}
[[Category:Ash Functions]]

Except {{{parameters}}} needs to be replaced with a bunch more #ifs to generate the first line automatically. But you get the idea. This will allow us to have one template for all functions, and it won't matter if the ASH/CLI functions have different variables, we'll just call the template twice. We'd call the function like:

{{function|
name=retrieve_item|
ash=1|
returns=boolean|
description=uses KoLmafia internal logic to gather the items in the least destructive manner. ''See the “acquire” documentation in the CLI manual for more details.''|
p1=quantity|
p1t=int|
p1d=The quantity of the item you wish to retrieve|
p2=itemname|
p2t=item|
p2d=The name of the item.|
examplecode=# function to get your class-specific Epic Weapon hermit item
boolean get_epic_item()
{

  item[class] epic_items;
  epic_items[$class[seal clubber]] = $item[seal tooth];
  epic_items[$class[turtle tamer]] = $item[chisel];
  epic_items[$class[pastamancer]] = $item[petrified noodles];
  epic_items[$class[sauceror]] = $item[jabañero pepper];
  epic_items[$class[disco bandit]] = $item[banjo strings];
  epic_items[$class[accordion thief]] = $item[hot buttered roll];

  return retrieve_item(1, epic_items[my_class()]);

}|
}}

 

[fronobulax]

Wow. This is fun. Some random comments of no interest to anyone but me.

First, I am in favor of any choice that the folks who actually volunteer to do the work find makes their job easier and the end product better. My sense is that hammering out an agreement on templates will do this.

In many ways the Java API documentation is "the gold standard" for documentation. Parentheses are not relevant there when it comes to finding something. I understand the concerns that a CLI function and an ash function will have the same name, but how different will they really be? Would a page with the function name (without parentheses) that described the functions and then had usage examples for both CLI and ash work? If not, I would err on the side of making it easier for the ash user than the CLI user. Just selfishness on my part, but it does seem to me that the CLI documentation is pretty straight forward and I am hard pressed to suggest improvements to what has already been done and I see no real user focused benefit to mixing CLI and ash documentation. If I know I want CLI I would go to that page, otherwise I'd rather have a search take me to something with ash and CLI than a disambiguation page.

IRC channel noted although I have a personal preference for forum discussions because they are archival and access is not blocked by nanny software.

 

[zarqon]

If we go with functions w/o ()...

But there is no such thing. They are a language construct, which is why they should be included, since this is a Wiki for that language.

On that score, the main reason I vote for parentheses is because it will help new scripters to understand (by showing rather than telling -- always more effective) how a function is specified in ASH. It will firmly entrench in their minds that functions have parentheses after them. Because they do -- every last one of them. A clear association between functions and parentheses, as distinct from mere variables, is beneficial to learning scripting. Further, a scripter knows at a glance whether something is a function, merely based on the presence or absence of parentheses. It would be nice for the Wiki to be equally easy to understand at a glance.

As a side note -- I foresee the eventual adding of mafia settings as well. What they mean, default values, possible values, what you can do by changing them. They are a vital part of scripting.

I agree with fronobulax -- this is fun! I started doing editing work on the Wiki about a year ago (?) and gave up because a) supporting my scripts is extra-KoL work enough, and b) I didn't ever fully understand Wiki syntax / templates / all the technical stuff you can do with Wikis, and I was sure I was being vastly inefficient somehow. I would be much happier to contribute if I could do so without writing each page from scratch!

If it helps, here's the outline I wrote up long ago for Wiki content, edited a little bit for relevance:

Data types
-boolean
-int
-float
-string
-buffer
-records
-maps (don't forget 'remove' and 'contains')
-arrays
-typedef
-mafia's unique typed constants
(item, skill, monster, location, familiar, effect, stat, class)
-plural typed constants

Variables
- declaring
- scope: global vs. local (some vars are passed by reference)

Commands

Flow Control

Operators

Functions

Script anatomy
-mainless script
-main (variables in main)
-keep things out of main for public option

Mafia-called scripts (run by mafia at various times/conditions)
-login/logout
-betweenBattleScript
-postAscensionScript
-preAscensionScript

Mafia-defined scripts (same as above but need a specific main() declaration)
-consult scripts (see also : combat filter)
-recoveryScript
-counterScript
// these are here or above?
-buyScript (?)
-chatbotScript (?)
-plantingScript (?)

Comments

Import

Notify (include "script" keyword)

Tricks
- submitting forms using visit_url()
- parsing page text (matchers, index/contains)

ASH functions
(what it does, possible abort errors, using return value, server hits, CLI equiv, categories, logged-out)
- your character
- item management
- equipment
- familiar
- skills and effects
- adventuring
- combat
- misc
- datatype conversions
- string-handling routines (matchers? at least link to some other regex tutorial)

CLI commands
(what it does, possible abort errors, server hits, ASH equiv, logged-out)

Mafia settings
-single page for choiceadvs
-single page for BM encounters
-perhaps group pages for other related settings, since people usually want related info -- i.e. IsleWar settings, daily actions settings, consumption settings
-ASH equiv, e.g. my_ascensions() for knownAscensions, or my_fullness() for currentFullness.

 

[StDoodle]

Ok, let's see if we can gather the informational requirements (again, I'd rather save actual template-writing until we're pretty sure we've knocked out all of the basic requirements).

• Need a way to show page type. I like "ash=1" "cli=1" etc. Leaves things flexible for adding-on or just doing alternate templates, as seems prudent at the time.
  
  
• Some functions can be called with different numbers of parameters. I'd really like to move towards listing the function once, with optional parameters in square brackets when possible. Still need to account for the fact that a few functions actually use completely different parameters, so we could either pipe-display them (remembering to escape the pipes -- I believe {{!}} is the way on wikis -- or list the function multiple times. I think the latter would be clearer, but I don't want to stray too far from whatever standard practice might be. The to_string() function is one example of a function that could get messy if we try to list all of the options on one line.
  
  
• Optional parameters will need a "defaults to" flag (probably in the parameter template).
  
  
• I'm still favor a separate template for parameters (mostly for ease of changing around how they are displayed, but for segregation reasons as well). They could easily e called in the template reference with "p1={{param | type | desc | more_info_if_needed}}" and "p2=..." etc.
  
  
• Similiarly, a template for displaying the function itself, as oppossed to the function page, may be a good idea. Would probably make it easier to deal with pages (such as that for to_string()) where we may want to display the function several ways. Could be referenced similiarly to parameters.
  
  
• Obviously, description & code samples should be handled in the function template. Keep in mind that multiple code samples would be useful for many functions, and sometimes these need their own descriptions. I hate the idea of hard-coding a cap on such things, which makes me lean towards having templates for them as well (I haven't yet seen a good way to parse information similar to a foreach kind of thing in wiki template).
  
  
• Though I never code ash that way myself (too much LISP), I know a lot of functions can be called method-style. We should probably include a "method=" flag in the template that allows for an automatically added "This function can be called as a method via foo.{{name}}()"
  
  
• There should be support for a list of "see also" functions / links.
  
  
• There should be support for "See this thread for discussion"
  
  
• Built-in disambiguation / "Were you looking for the CLI command..." would probably be a good idea. Or perhaps "There is a similar CLI command...", I dunno.

I would be interested in hearing about any other stuff that should be built-in to the templates before we attempt to actually create them. Please let me know what's missing.

Also, it might be a good idea to do "mock ups" of some pages, just so we know what we want the end results to look like. Perhaps we should start a "mock-ups" category on the wiki, so the whole category can be deleted once headway is made. I dunno.

I'm not quoting fronobulax as his post was after I started this one & I'm lazy this morning, but I do want to add that I think, for the most part, the CLI documentation is good enough on that page, and in general a primer (such as we have a thread for already) with links to that page should probably do the job as far as CLI documenation goes; I'd really rather the wiki focussed on ash, which is a bit more in need of individualized explanations. Again, just my opinion.

Argh, then zaragon posts, and it's too much not to quote!

They are a language construct, which is why they should be included, since this is a Wiki for that language.

Thing is, I'm not in any way endorsing showing the functions without parentheses except in the page name. Of the several documentation wikis I've looked at, not one used parenthesis in the page name, probably for reasons I've already mentioned. Truth be told, unless we can come up with some miraculous solution, I fear sticking with the current "parentheses in page name" method is going to result in so much fiddly bs being required that I'm going to lose all interest. (I apologize for being so "whiny" on this subject, but it really touches a nerve with me, for some reason. To elaborate slightly, my life kind of sucks right now & this was intended as a "get my mind of off real life" diversion. But it means I'll be extra-prickly, for which I apologize.) Yes, I think the ideal solution would be for wikis to simply work differently than they do, and handle all of the redirection needed automatically / in the background. But they don't. Aside from getting things off the ground, I really don't forsee requiring all future edits to the wiki to add new functions requiring the author to make sure a re-direct page is added and all references to the function to be piped for proper linking to be a good solution.

On that score, the main reason I vote for parentheses is because it will help new scripters to understand (by showing rather than telling -- always more effective) how a function is specified in ASH....

But not exactly in the way you're saying. I never call "visit_url()", I call "visit_url(some_page)". No offense (probably more of a compliment), I think I have a better grasp of how the non-programmer thinks about programming. It's not that I in any way advocate having function pages not explicitly lay-out how parameters should be passed, or how parentheses need to be added for a parameter-less function. I'm just talking about the page name.

As a side note -- I foresee the eventual adding of mafia settings as well. What they mean, default values, possible values, what you can do by changing them. They are a vital part of scripting.

Agreed; I'd like to get everything sorted for functions as the primary goal, but data types, mafia settings, etc. all need to be accounted for as well. I certainly think most of these deserve their own templates, and by all means we can try to sort those out here as well (again, at this stage I'm more concerned with information requirements than exact wiki template syntax).

 

[zarqon]

I never call "visit_url()", I call "visit_url(some_page)". No offense (probably more of a compliment), I think I have a better grasp of how the non-programmer thinks about programming.

My point was that the Wiki should made to influence non-programmers to think like programmers, and "visit_url" is not a function, whereas "visit_url()" is. You never call "visit_url()" without parameters, but you can't even call "visit_url" without getting an "unknown variable" error. I'm not going to insist, however. I made what I think to be a good point, but it's not that big a deal, and if ease-of-creation dictates a Wiki with no parentheses, then Wiki-reader thought-molding be hanged.

 

[fronobulax]

@StDoodle - Chin up. This is supposed to be fun for you. Please don't let it be otherwise

My focus on the parenthesis issue is strictly based upon finding things. I have never used a library in a programming language where things were over loaded to the point that both foo and foo(args) were library elements that needed to be documented. Thus when I am searching I presuppose a function library and that foo is the name of a function. I'd say about half the time I'm looking for a function reference what I really want is the signature (i.e name, return value and args). I don't care whether the "database" is organized with names like foo vs. foo() but I certainly do not want to see different results when I search for foo as opposed to foo().

Since I see the wiki as a reference and not a tutorial I don't place much value on reinforcing the fact that something is a function when the material is searched by coding n00bs. Anyone who uses foo when foo() is needed will figure out their mistake soon enough and will learn something in the process.

I note that the python and c library documentation can also be searched reliably without using anything to indicate that the item being searched for is a function.

I note that this discussion is getting to be like painting the bike shed. Thus I hope my opinions are not offensive and recognize that I am not necessarily helping us towards the goal by expressing them.

 

[Grotfang]

My point was that the Wiki should made to influence non-programmers to think like programmers, and "visit_url" is not a function, whereas "visit_url()" is.

I think you make a fair (technical) point, but I side with StDoodle on this one. Ashref produces function description that includes parameters, so the non-scripter won't see "visit_url()". They will see "visit_url( string )". To then show them "visit_url()" adds to confusion. Better to have a system whereby you refer to functions by name only without any reference to whether they are a function (ie. without the "()") and let the code snippet demonstrate the usage.

As a secondary point, I am quite keen to help out as much as possible and am perfectly willing to do plenty of grunt work. I don't know much about wikis, though (but am perfectly happy to produce code snippets and write up wiki pages for any and every function that needs it). If a template is set up, may I ask that it is clear for a non-wiki expert to edit its content. Currently pages such as this look completely bizarre to me and I wouldn't have a clue what all the {}s mean.

Finally, may I ask for some sort of advice to be documented on what makes a good code example. In my head, simpler is better but some code on the wiki seems also to try and show off. For example, why does the function creatable_amount() require the user to know and understand what map constructs do? While it's not a problem for me, it seems crazy for a wiki to demand knowledge that I think is more complex than what it is trying to document.

 

[fronobulax]

Finally, may I ask for some sort of advice to be documented on what makes a good code example. In my head, simpler is better but some code on the wiki seems also to try and show off. For example, why does the function creatable_amount() require the user to know and understand what map constructs do? While it's not a problem for me, it seems crazy for a wiki to demand knowledge that I think is more complex than what it is trying to document.

Finding good examples is an art form. The advice I have received elsewhere is that a good example clearly shows how the function might be used in the real world. If the example is simple then the suggestion has usually been to use multiple examples of varying complexity. If someone would cut and paste and then run the example because it actually does something interesting then that is A Good Thing. In this particular case I agree that maps are a complex concept, but I tend to think that one of the things that would drive someone to use ash, instead of CLI would be maps. Thus I have no problem presupposing some knowledge of maps in code examples.

I will note that in the ancient days when C programmers had to build and use sockets from library primitives, it was pretty hard to document the functions, or provide examples that used them without presuming the reader had some core understanding of both sockets in general and the several associated functions. Indeed, several of the functions used the same, identical code example.

 

[Grotfang]

If someone would cut and paste and then run the example because it actually does something interesting then that is A Good Thing.

I fully agree. However, different user abilities would see different things as being cut and pastable. For example, let's say I want a script that will make a rockin' wagon if it can, or otherwise stick with a vodka martini. What use do I have for a map then? I think having some sort of guideline for code is useful, and making sure that there are examples posted that show in their simplest form what the functions do is essential.

creatable_amount( item ) should be demonstrated in that exact context, without any confusion over how ( item ) is being included. That is my argument and I'm sticking with it. Including multiple examples is great and I think having more complicated examples can be useful, but at its raw level function x()'s documentation should not be contingent on more knowledge of data structure y than is needed.

 

[aqualectrix]

I would much rather we came up with a solid foundation of templates and standards, so that anyone who looked into it knew exactly what to do, and how, when going to re-write a function page. I'd like to make it incredibly easy for a casual wiki user to go through and edit pages in a standardized way as they see fit.

This is a wonderful goal!

As far as making things easy to add / making the wiki useful to an ash/cli newcomer, there's an additional component. We're discussing functions here, and having a more useful function reference is certainly a goal in itself. But the so-far-unmentioned elephant in the room is the language itself.

The typed constant page is a mess. Records are mentioned nowhere. Switch statements and search and plural typed constants weren't there until I added them a few months ago. I still haven't gotten around to adding typedefs. Sally's intro to scripting should probably go up (and her intro to Mafia, for that matter -- obviously both only if she's okay with it).

It's not that I'm not willing to add language features that I know about but aren't on the wiki. That's the point of a wiki -- stop complaining and do it yourself! But I feel like I'm just sort of plopping information into whichever language page it might fit on (better than nothing, certainly). (I'm also less than confident about my ability to explain things clearly, which is why much of what I've added has been more-or-less straight copy-and-paste from commit logs or forum posts by other people.)

Which is to say, regimenting language features might be a lot harder, because there's probably no one template that can really handle them. But if anyone more wiki-aware than I has guidelines or suggestions for how pages like the typed constants page should be cleaned up, or how much other-programming-skill should be assumed when explaining ash programming language features, or anything like that... well, I'd be glad for some guidance.

Re: parentheses:
As a programmer, the parens are part of the function name for me. They're the part that signals that this is the name of a function, not a variable, and when I'm just identifying a name as a function, the parameters aren't necessarily important. Thus I would talk about put_shop() to identify that I was talking about a function, and leave out the parameters because I don't like to type that much (also, since put_shop() is overloaded, leaving out the parameters lets me talk about any version of the function). From this point of view, the parens are part of the name and should be in the title. Redirects ahoy!

On the other hand, I'm not sure that distinguishing between cli commands and ash functions in page names is a necessary thing. Why not let identically-named commands/functions share a page? If you search "autosell" there's no smart way to figure out whether you want cli or ash, so if they are separate pages we'd ideally go to a disambiguation page. But why not just go to an Autosell page that describes both cli and ash? It's not like there are many functions for which the description is likely to be very long -- when both are still visible above the fold and in the little section-box-thingy at the top of the page, there's not a lot of chance of confusion that you've reached the wrong page ("Oh, but I wanted the ash version and I'm at the cli page" type confusion.)