Wiki Updates (masochism?)

[StDoodle]

Attached is my attempt...

That would be pretty nifty, but I'm going to leave that up to fewyn for whether or not he wishes to try that, since he's the one who'd get to deal with fixing anything if it goes haywire.

Templates have been updated! Documentation is kind of lacking so far, but if you check out the page for my_name() in edit mode, you'll see part of what's going on as well as the templates used.

Helpful instructions to come shortly!

Edit to add: Would it be possible for me to be added as a wiki admin? At least once I've proven my dedication? I'd like to be able to lock the Template pages, but not yet (without the ability to unlock, anyway). I'm not clear on what the various wiki user permissions are, but if there's one that just adds lock / unlock privileges, that would be super!

 

[Bale]

Tried it out, but unfortunately the return type for get_related() does not work properly.

Aside from that, awesome work!

 

[StDoodle]

Tried it out, but unfortunately the return type for get_related() does not work properly.

Aside from that, awesome work!

Thanks! I forgot to handle aggregates, doh! One question; I can't see any situation where you would sanely have the same function return different data types in overloaded situations, but I just want to make sure I'm correct on this. If I am, I can get rid of some cruft, simplify the template, and make it much easier to handle aggregates.

Edit: Alhifar pointed out buy()... ouchy. I'll come up with something good, though; no worries.

 

[zarqon]

Different-return-type overloading is possible, so it should probably also be possible in the Wiki. Although it's not a native ASH function, the first example that comes to mind is ZLib's has_goal(), which can return either a float or a boolean, depending on the parameter passed.

 

[Veracity]

No.

float has_goal(item whatsit)
vs.
boolean has_goal(monster m)

overloads on the parameter, not the return type. It is not possible to have two variants of a function with identical parameters and different return types.

 

[zarqon]

Oh, I thought that (same name, different params and return type) was what he was talking about. Obviously same name/parameters and different return type isn't possible since there would be no way to know which return type was desired.

 

[StDoodle]

I'm looking at it from the point of view of organizing the wiki, so my terminology may well be off or unlcear, apologies.

Using buy() as an example, it's probably best to put both versions on one page to avoid confusion. Which means the wiki template needs to support both differences in parameters AND differences in return types. I'm confident the solution I have in mind should work & avoid unnecessary parameter assignments for typical cases, but a little re-working will be required.

Also, I'm removing the language specification for the <syntaxhighlight> tag in the template. Since such tags (as well as <pre>) can't be used inside of a sub-template, there's no sane way to set it up so that any future changes could be pushed to existing pages, except by setting a default "lang" attribute on the server. What this means is that any pages that make use of the FunctionPage template, with a code sample, will show an error in place of the code sample until "lang" is set.

I'll have the new version of FunctionPage up shortly, with support for aggregate types & all of the rest of what's been discussed. If anyone feels like making use of it, please make sure to omit a "lang" specification in the saved version of the page (feel free to use it for testing, just please remove it). The problem should correct itself shortly.

Also, please chime in if there's anything I'm missing or doing "wrong." Feedback is always nice!

 

[Bale]

zarqon, tell me if you approve of my second example here. (Trying to keep it a little simple, so I'm not adding checks for wand heat state.)

 

[zarqon]

Hahaha, of course I approve. I should even say thanks!

I do have a few comments, however:

1) Can we make every ASH function call in code examples clicky? It would be quite handy, especially at the beginning where you're not sure what the other functions in code examples do, or when you see a function used in a way you are not familiar with. Much handier than having to search.

2) Is it a single pipe or a double pipe separating the message for the CLI "send" command? I'd thought it was a double pipe.

3) Is there a See Also section in the template? Seems like get_inventory() and especially get_ingredients() would be nice to see on this particular page.

This is great, everyone! I'll be happy to add stuff once the templates have been sorted out, and perhaps a brief guide on how to contribute has been posted -- otherwise, I don't know what I'm doing and think I might mess something up.

 

[StDoodle]

1) Can we make every ASH function call in code examples clicky? It would be quite handy, especially at the beginning where you're not sure what the other functions in code examples do, or when you see a function used in a way you are not familiar with. Much handier than having to search.

Well, we can either have the highlighting or we can use markup inside of the example, but not both. I'm honestly not sure which way to go on that; it would be really nice to have both. What does everyone think?

3) Is there a See Also section in the template? Seems like get_inventory() and especially get_ingredients() would be nice to see on this particular page.

That would be the "see_also" parameter.

This is great, everyone! I'll be happy to add stuff once the templates have been sorted out, and perhaps a brief guide on how to contribute has been posted -- otherwise, I don't know what I'm doing and think I might mess something up.

Yeah, I don't want to have too many updates done before the templates are finished, or it will just mean a lot of re-work. I'm hoping to finish the templates this weekend, and will try to do so as soon as a couple changes get added in to the wiki. If we decide to favor links in code examples over highlighting, one of the changes isn't required. However, the other change is kinda necessary to avoid a huge deal of cruft in the templates.

Unfortunately, my free time will go way down after this weekend, so if I can't make the changes then, it may be a good while.

 

[Bale]

2) Is it a single pipe or a double pipe separating the message for the CLI "send" command? I'd thought it was a double pipe.

The other day, when I sent you bat parts, like I often do, was there a message? I used a single pipe. If the message was blank, just a list of bat parts without any comment, then I did it wrong.

Well, we can either have the highlighting or we can use markup inside of the example, but not both. I'm honestly not sure which way to go on that; it would be really nice to have both. What does everyone think?.

I agree. Both would be nice. If I cannot have that, I prefer syntax highlighting since it makes code so much more readable. I feel very strongly about syntax highlighting. And in my PMs I've had someone very new to coding thank me for the highlight that the [php] [/php] added to some examples I sent him, so I think coding newbies like it also.

 

[heeheehee]

Can someone clarify why it wouldn't be possible to have both?

Also, I'm voting (if my vote means anything) for the quick-link. Any of the base functions will be identified as such, as opposed to syntax highlighting... which doesn't highlight anything ASH-specific.

So unless we decide to use that custom language file I hacked together (in the sense that it's a crude attempt) or something similar, I think that the linkage would be more useful for the time being.

 

[zarqon]

I like highlighting too. One possibility would be to have any functions used in the examples listed and linked directly below the example, e.g.

Functions used in this example: cli_execute(), min(), print().

But both would be better if possible, particularly if it were automatic in some way.

 

[fewyn]

Installed http://www.mediawiki.org/wiki/Extension:VariablesExtension at request, also put in the ash highlighting by heeheehee and set it as the default language for highlighting.

 

[heeheehee]

Awesome, thanks! I made a few changes regarding aesthetics (For instance, I totally didn't realize that strings were blue), so this update shouldn't be high priority.

 

[StDoodle]

Regarding syntax highlighting vs. using links:

The current (and only decent) sytnax highlighting extension I've found basically works like a <pre> tag, so any formatting will be stripped; markup will print as typed, instead of being turned into links.

One thing I forgot to mention is that if we use a custom color set for highlighting, it would be best to avoid the blue, purple and red used for links in a wiki. Seems to me like it could get confusing.

One thing we could do is just try to include any functions used in sample code in the "see_also" parameter.

 

[heeheehee]

Okay, will fix those colors (in the post two or so above this one).
Edit: Although I think it'd be really cool if we could have those colors also be links. The CSS base of GeSHi would make that possible, in theory...

Double edit: Red links are #BA0000; I've been using #FF0000 for datatypes. One's more vibrant than the other... Is this a problem? Changed the blue of functions to be lighter and almost impossible to confuse with the blue of a link, made the pink of control structures paler.

 

[StDoodle]

The CSS base of GeSHi would make that possible, in theory...

I haven't really looked into the interaction with GeSHi & the SyntaxHighlighter extension; if you think it would be possible to make everything that's recognized as a function into a link, by all means do so... it would be helpful if such links could follow the coloring of wikis, but if only one link color is feasible, by all means use the regular blue of a "normal" link.

Double edit: Red links are #BA0000; I've been using #FF0000 for datatypes. One's more vibrant than the other... Is this a problem? Changed the blue of functions to be lighter and almost impossible to confuse with the blue of a link, made the pink of control structures paler.

I'd say as long as the colors are readily distinguishable from each other, it's good. Again, just try to avoid all the link colors & indistinguishable variants UNLESS everything made that color actually functions as a link, in which case going with the default blue is good.

The really good news about the situation is that since fewyn has been kind enough to set a default "ash" language for syntax highlighting, we can play around with this until everything is good, and then when the changes are pushed to the wiki, all template-compliant code will automatically get updated to the new color scheme. Yay!

Also, I plan to have the redone templates up by around 2-4 hours from now, so we should be able to get some srs bzns done by the end of the weekend!

 

[jasonharper]

Proposed logo for the wiki:

 

[StDoodle]

Proposed logo for the wiki:

Awesomesauce, IMO.

Edit to avoid double-post:

I'm pretty confident I've got the template cleaned up & where it needs to be for mass-use. It's possible minor tweaks & additional parameters will be added, but nothing that should require all pages using the templates to be re-done (at most, they'd warrant the addition of a line or two, but it's nothing at this point that should "break" anything).

I'm less confident about my explanations of how to use the templates; I've been staring at it all so long, it kind of blends together in a massive blur.

Feedback on understandability and such would be greatly appreciated.

And, once again, let me know if I forgot to include support for something (aggregates are fully supported now, even a few edge-cases that should NEVER exist).