User talk:Smls

use of the   {{out}}   template

Since you're into templates, do you know if the   {{out}}   template can support the adding (or appending/concatenating) of text to the bold   Output   "title"   (and keep the additional text   on the same line) ?

(I have no idea where the template is kept, who can modify it, or if it can be changed.)

I normally use something like   (usually immediately after the   </lang>   HTML tag):

 '''output'''   when using the input of:   <tt> 12   -6 </tt> 

which renders to:

output   when using the input of:    12   -6 

and some people (or person) have been changing the   '''output'''   when using ...   to

 {{out}} when using ... 

which renders to:

Output
 
when using ...

which changes the apparent antecedent of the   when   and modifies my (original) meaning of the phrase.

Also note the additional blank line.

I understand it would be nice to have all the computer programming entries use (more or less) the same (if not a constant) template, but I don't know where the options for (this particular) template(s) are documented (if at all).

At this point, I'm not sure if it is worth the bother, as I certainly don't have the timer or inclination to change over a thousand of my entries.   (I'm not sure of the number, but I think over half of my REXX entries have multiple   output   sections, almost all of them have appended comments.)

-- Gerard Schildberger (talk) 02:39, 25 August 2016 (UTC)

Sure, that kind of template extension is easy. Strangely enough, the {{out}} template already accepted an an undocumented positional parameter to replace the word "Output" with something else, as in {{out|Return value}}. To be safe I left that as it was, and added the new options as named parameters instead. I also put some usage documentation on the Template:Out page. Does it suit your needs now? --Smls (talk) 07:02, 25 August 2016 (UTC)

(Regarding   <tt> .)     I didn't know what the   <tt>   tag was (supposed to be) used for.   Again, somebody was changing my many texts showing what the "input" was for the program (for the output section to be shown as   <tt> ,   and I just assumed that was some Rosetta Code "standard" or commonly accepted protocol.   So I've been blindly using that protocol ever since.   Again, I didn't want to make a point of it or question it as the bulk changes where done (as I recall) by an administrator.   -- Gerard Schildberger (talk) 21:05, 25 August 2016 (UTC)

Both <tt> and <code> are fine for showing inline monospace text such as input data or code fragments. I prefer to use <code> in for data that may contain spaces, because it is styled with a subtle background color and border and thus makes it easier to see where the fragment starts and ends. --Smls (talk) 10:28, 27 August 2016 (UTC)

(Regarding my needs.)     Not quite suiting my needs, but very very close.   The   comment=   keyword adds a pre-pended double dash as well as a trailing colon.   I would like another keyword   (say, TEXT=)   which wouldn't add anything and let me specify in its entirety what text I wish to use for the cases of when a double dash and/or colon isn't quite appropriate.   -- Gerard Schildberger (talk) 21:05, 25 August 2016 (UTC)

Done. --Smls (talk) 10:28, 27 August 2016 (UTC)

Thank you.   You epitomize what the Rosetta Code spirit and philosophy is all about.   -- Gerard Schildberger (talk) 20:16, 27 August 2016 (UTC)

general feelings about (some) templates

An oversimplification of past experiences in the distant past ··· but my overall feelings of templates (experienced here on Rosetta Code) is that templates have a tendency to be used to pound square pegs into round holes,   or at least, that's my observations with the few that impacted my many numerous entries on Rosetta Code.

Either the templates don't have the flexibility (or the necessary options) to support what I want (or my meaning), or the people don't know that the converting of (header or title) text into a form that they weren't intended for   (or they/it may have changed the original meaning or intent).   I always thought that templates were mostly used (in the templates that I normally used) for general text (for instance, headers, titles and such)   and to supply a shortcut or abbreviated method to (help) express it succinctly.   That is, to be used as tools, not necessary as a method to enforce conformity.   -- Gerard Schildberger (talk) 03:12, 25 August 2016 (UTC)

new test cases for "extract file extension RC task

Since you replaced all the test cases for the Rosetta Code task   Extract file extension,   you should probably do two additional things:

• mark the (draft) task as being updated and that most computer language entries need to redo their programs (or, at least, update the test cases)
• pink flag most of the entries as "needing updating" (or somesuch wording) to use the new test cases.

Technically, most of the entries are now "incorrect".

-- Gerard Schildberger (talk) 17:30, 31 August 2016 (UTC)

I wouldn't call them incorrect just because they use different examples. Flagging them with the needs updating template for that would feel a bit harsh, no? Of course, some of the entries might be incorrect because they never read the task carefully, and instead wrote their code around the old examples (which caught fewer edge-cases implied by the task description), or even just read the page title. But that's a problem that many tasks suffer from... :) --Smls (talk) 06:24, 1 September 2016 (UTC)

Er, no.   It's not they used different   examples,   but different   test cases.   That's why they are called   test cases,   they're to be used to prove (test) that the code works correctly and the test cases are to be used for validation.   There's nothing wrong about   adding   test cases (of the programmer's choosing, that's done all the time), but the task's test cases are to be used as part of the task's requirements.   Otherwise, why have test cases?   Test cases are there to have some kind of conformity among the programming entries so as to make them easier to compare.   Sometimes, instead of test cases, they are labeled examples, which may or may not be used as part of the task's requirements.   This is one reason why test cases are added to instead of replacing them   (almost always while the task is still in draft status).   -- Gerard Schildberger (talk) 17:39, 1 September 2016 (UTC)