I'm working on modernizing Rosetta Code's infrastructure. Starting with communications. Please accept this time-limited open invite to RC's Slack.. --Michael Mol (talk) 20:59, 30 May 2020 (UTC)

User talk:Smls

From Rosetta Code

use of the   {{out}}   template[edit]

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[edit]

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[edit]

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).   But I understand your reluctance to flag (almost wholesale) most of the programming entries, but that's the price of changing test cases.   It's an easy thing to fix (or accommodate).   -- Gerard Schildberger (talk) 17:39, 1 September 2016 (UTC)


I've added the "update needed" templates on this page now, because some of the solutions seemed confused by the ambiguity of the old task description anyway, so it's good to have them looked over now that the task is clearer. However, in general I disagree with your notion that the existence of test cases below the task description implies a strict requirement for solution to show those particular inputs and outputs on the page... --Smls (talk) 10:03, 4 September 2016 (UTC)


"Otherwise, why have test cases?" — As an aid, not an obligation:
  • It says to programmers who want to add solutions: "Hey, here are some unit tests that can help you implement your code correctly, and to clear up any uncertainties you might have about the task requirements".
  • Even if the task description is already super precise about all requirements, a table of test-cases helps to see at a glance what the task wants you to do, so people can decide more quickly if they even want to attempt to solve that task, and what it would involve.
  • Not to mention that writing the test-cases helps task authors think about potential problems and edge cases, resulting in better written and more focused tasks, so it's a good thing to encourage.
I think those are plenty of reasons to have them, without interpreting it as a strict task requirements to actually demonstrate them. In tasks I've written, I've usually added a sentence like "Demonstrate that it passes the test cases given below" to the task description if I thought that was particularly important for the task in question (e.g. Brace expansion), and not for other tasks.
--Smls (talk) 10:03, 4 September 2016 (UTC)


"Test cases are there to have some kind of conformity among the programming entries so as to make them easier to compare" — Consider tasks like Compiler/lexical analyzer where the test-cases are very long, and produce a strictly specified output. I don't think having an exact copy of the same long {{out}}<pre>...</pre> block under each solution would do anything for comparability there, it would just make it harder to browse the page. So I think it's prefectly reasonable that the solutions on that page have opted to only show one of the test-cases. In general, I think people should have some leeway as to what inputs and outputs they show. Yes, a solution should pass all the official test-cases, but it shouldn't strictly be forced to demonstrate that on the page. RosettaCode is primarily meant to compare the code that solves the task's problem, not to compare repetitive demonstrations of how to use said code.
--Smls (talk) 10:03, 4 September 2016 (UTC)


"Sometimes, instead of test cases, they are labeled examples" — I would avoid the word "examples", because in many places on RosettaCode that word is already used to refer to the solutions / code entries on a task page.
--Smls (talk) 10:03, 4 September 2016 (UTC)