User talk:Gerard Schildberger

From Rosetta Code

Flag as incorrect[edit]

Hi, I think you left a comment the above will erroneously return:... on a PLI example. Could you change this to use the template incorrect so that PLI users are flagged that the example needs attention. Thanks. --Paddy3118 18:22, 28 October 2010 (UTC)

I confess I didn't know the proper methodology to be used (this was my very first time on Rosetta Code). The fallout from that excursion was not what I expect at all, not exactly a pleasent experience. It would've been nice to actually include the righteous text so I could hit the ground running and re-enter the correct incorrect template. I had thought that putting a comment near the code would get someone's attention and fix the problem. My bad. I was trying to figure out how to contact the author of the code, but I didn't have the skills at that time. I have previously removed the offending comment, leaving the original problem intact, and as far as I know, the errors are still there. To make it worse, I've already forgotten which entry it was, and looking back at it all, I regret trying to address the issue (error). There are so many such errors that I came across a few weeks ago, and I'm glad I didn't mung up more erroneous pages. I'm wondering at this point if erroneous pages are less erroneous with erroneous corrections? I wish the process would be more forgiving and above all, much easier to implement without the headaches. If I ever get the time, I may revisit some pages, but I rarely look at other people's code anymore, except for clarification of the specifications of the task to be solved. What is the protocol about these talk pages? Do they hang around forever, or am I supposed to delete (edit) them later when they lose their relevance? Gerard Schildberger

flagged REXX ISAAC incorrect; Classic REXX vs. ooRexx[edit]

Gerard, I notice you have flagged a REXX solution to my task "The ISAAC Cipher" as "incorrect". This REXX program compiles and _works_, so perhaps you'd be so good as to explain what is "incorrect" about it. Alternatively, you might like to enter your own REXX solution beneath that to demonstrate how you think it _should_ be done? --BlaiseP (talk) 05:40, 25 July 2014 (UTC)
What doesn't work are the two ooRexx constructs that aren't valid syntax in (Classic) REXX (where it was entered).   Perhaps you should be asked which Classic REXX was used to execute the program.   If it was ooRexx (as it has ooRexx constructs), it should be entered in ooRexx.   However, since you didn't run this example with any Classic REXX, I'll save you the trouble and show you the error that Regina REXX returns --- as well as PC/REXX, Personal REXX, R4, and ROO (and others), it would be illegal in CMS REXX, TSO REXX, and other Classic REXXes also:

For Regina REXXes (all versions):

D:\►regina issac
Error 35 running "D:\issac.rex", line 91: Invalid expression
Error 35.1: Invalid expression detected at "="

For R4 REXX:

D:\►r4 issac
Invalid operator character sequence
Error detected at line 91 offset 5
Source line:

For PC/REXXex and Personal REXXes (all versions):

D:\►rexx issac
Error 35 on line 91 of D:\ISSAC.REX: Invalid expression


D:\►j:\-\roo\roo.exe issac
Invalid operator character sequence
Error detected at line 91 offset 5
Source line:

I hope that clears up the confusion.

Also, note that there are two separate errors.

As for entering a correct version for REXX, I'm confident that the original author will fix the program. -- Gerard Schildberger (talk) 06:07, 25 July 2014 (UTC)

Update:   it was just corrected. -- Gerard Schildberger (talk) 06:07, 25 July 2014 (UTC)

Thanks for the interesting elucidation and correction. I'm no REXX expert, but just wondered about the flag. This seems to be a little like the differences between standard Pascal, Extended Pascal, and Delphi - all rather trivial, but handled very efficiently by compiler options in Free Pascal. It's just a matter of including a $mode switch at the top of your program code. Doesn't ooREXX have anything similar? --BlaiseP (talk) 08:03, 25 July 2014 (UTC)
REXX and ooRexx have two different and separate language entries as they are separate languages (although there are some that say ooRexx is REXX).   Entering (I should think) a language entry under another language (that doesn't work for that language) should be considered an error.   Entering a C entry under FORTRAN would also be wrong, even though executing it would still produce the correct results.   It was the using of an ooRexx program under REXX that was flagged as incorrect, not the results of the program.
ooRexx is an object-orientated language and has many language features (or extensions, if you will) that support o-o programming, and there are syntactical differences as well, not to mention that there are (Classic) REXX constructs, symbols, BIFs (built-in functions), and other syntactic sugars that aren't supported in ooRexx --- and of course, vice versa.   It would be like comparing   C   and   C++   (I think --- I'm not an expert in either of those two languages).   To answer your other question, there are no flags that allow any flavor of REXX to allow the other's syntax for functionality, although the Regina REXX interpreter has options to force strict ANSI compliance, and/or to allow various flavors of some (older) REXXes that were developed on different platforms (such as Arexx), and other such minor differences that were introduced in later versions.   Most REXX flavors differ in what BIFs are supported.   All modern (Classic) REXXes (that I know of) support almost all older REXX BIFs and syntax.   There are always exceptions, of course. -- Gerard Schildberger (talk) 08:44, 25 July 2014 (UTC!
WAY too much hassle about two (2) little i+=8 statements! All my programs under REXX (should) run under your classic REXXes. Nearly none of your programs can be run unchanged under ooRexx (due to these minor differences with @#§ and x=;) Yes, ooRexx is MUCH MORE than Rexx and when I use its features I put the code under ooRexx. i+=+8 is certainly not a reason to do so. --Walterpachl (talk) 09:18, 25 July 2014 (UTC)
No, that's not correct.   Not all programs (prior to your latest correction).   As obviously shown above, the ooRexx program didn't run under ("my"?) Classic REXXes.   I don't own the REXXes nor are they mine.   As for my Classic REXX programs, I have no interest in ooRexx (as I have said so many times before).   Nearly is an important word there, and since I don't have an ooRexx, I can't say that they will execute under ooRexx, nor do I want to have to check yet another different language (ooRexx) to verify that it can/does execute correctly with Classic REXX code.   My only interest is writing Classic REXX code for ... Classic REXX.   But aside from that, using an ooRexx construct is a valid reason to put the ooRexx entry in/under the ooRexx language section.   Either that, or change the REXX program to execute correctly (for under Classic REXXes, which you have done).   Using a construct that produces a syntax error(s) for the language it's entered under isn't being helpful, all of the Classic REXXes will produce a syntax error on those statements that only work for ooRexx. -- Gerard Schildberger (talk) 21:28, 25 July 2014 (UTC)
We're talking about _dialects_ here, I think. Should two dialects of one language have separate RC entries? My answer would be "certainly not!" Yes, I know there are separate entries here for Pascal and Delphi too, but there _shouldn't_ be. Ditto REXX and ooRexx and probably a host of others. IMHO, "Delphi" should be deleted as an entry, because it is just Pascal with Objects, like Extended Pascal and probably several other implementations of the ISO Pascal extensions. All this nit-picking over dialects is just plain unconstructive... --BlaiseP (talk) 09:36, 25 July 2014 (UTC)
No, we aren't talking about dialects, but two different languages.   Of course, the first thing to do is agree on a definition of terms, and how those terms would apply to the languages in question.   I certainly don't want to even attempt to accomplish such a task.   This is obviously a very contentious area.   Because of this, it's a very good idea to keep Classic REXX and ooRexx separate, leastwise there'll be so much more of this type of conversations, with nothing being solved or accomplished.   Just saying that Classic REXX and ooRexx are the same language doesn't make it so, even though there is a lot of overlap of instructions, syntax, BIFs, and whatever, but as you observed in the above (error producing) examples, all of the Classic REXXes (that I have easy access to) received a syntax failure (error) in the program in question.   To someone reading Rosetta Code looking at Classic REXX solutions, it isn't constructive in learning Classic REXX when the REXX program produces syntax errors.   This isn't nit-picking, there are enough differences between the two languages to keep them separate at this late point.   Lumping them together at this time would mean more confusion/disagreements and would make it harder to find a Classic REXX solution.   I can't speak to the issue of Pascal and Delphi, but each language has enough differences to warrant separation, and I certainly don't want to be the instrument in unringing that bell;   I think it's way to late for something like that, assuming that would be a good idea in the first place.   [A while back, not too long ago, someone tried to combine the various BASICs together under one category (not languages), and that was quite the ... ruckus (my interpretation) ... as it was.]   Lumping programs together into the same language entry would mean explanations as to what programs are what and which REXX language it executes under (and/or which REXX is required), and it would be harder to find/search for programs in whatever "dialect" (if indeed, they are dialects) is being searched for.   [It helps that there is only one ooRexx, so that makes it simple to have an ooRexx language category.   I have yet to see a comprehensive least of the differences between the two languages, and when a subtle (my word) difference is noted, it causes much heated discourse and debate on such newsgroups like comp.lang.rexx --- one such difference is in the use of stems (arrays) --- but this is only important if one tries to use a Classic REXX program (or snippet of code) with ooRexx --- and the result is different.]   But as it is, REXX and ooRexx are separate language entries (in Rosetta Code), and as such, if someone enters an ooRexx language entry in the (Classic) REXX language entry, than it should work with (any?) Classic REXX interpreter.   If that were done, we wouldn't be having this discourse.   In short terse terms, if you enter a language entry, execute it with that language for that entry.   If someone wants to enter ooRexx programs, then use the ooRexx language entry.   It would be a disservice to assume that a person who wants to see a (Classic) REXX program work, but the example entry is using an ooRexx program and it isn't suitable for their (Classic) REXX environment (for whatever reason).   I can see two large uses/reasons for entries in (Classic REXX) in Rosetta Code:   learning the Classic REXX language (by observing program examples), and/or borrowing the code to work with any Classic REXX (or at least, a Classic REXX). -- Gerard Schildberger (talk) 21:28, 25 July 2014 (UTC)

After observing the above discussions, it's clear to me (at least) that combining Classic REXX with ooRexx would not be a good idea;   if it takes this much discourse in correcting a trivial mistake (or an oversight at the very least), think of the implications and what it would mean for 600+ more entries that would need identifying with what "dialect" of REXX that that particular program language entry would need to be executed under (and that's just for the Classic REXX programs);   ooRexx entries would also need such identifications and caveats --- unless there is so much enough naivete that the differences between Classic REXX and an object-orientated REXX language version are too trivial to mention.   And that's not counting the combining of Delphi and Pascal and many other such o-o language combinations.   I cannot see the benefit of such an expensive enterprise.   [This would be a good time to mention that time is very cheap, as long as somebody else is spending it.]   Lets keep separate languages separate, even though they may be defined as dialects (correctly or incorrectly defined).   Perhaps it would be a good time to have a fat, er ..., heavy Rosetta Code persona (pros from Dover) to weigh in.   (No insult intended, of course, of course --- I was attempting to refer to a person's own gravity well.)   Harrumph!   Harrumph! -- Gerard Schildberger (talk) 22:45, 25 July 2014 (UTC)

We must distinguish between languages and implementations. ooRexx, if you will, implements a subset of Classic Rexx and I am happy with that. Programs written obeying this subset have their place under REXX. Programs that use oo and other extensions (i+=8) should and must go to ooRexx (or be corrected). Again: thanks for telling me about my oversight. --Walterpachl (talk) 05:44, 26 July 2014 (UTC)
I'm almost in complete agreement with your first two statements (quite possibly 100%). Classic REXX interpreters that implement the same set of language syntax (rules), with minor differences, contribute to the making of computer programming language dialects.   ooRexx has different BIFs, statements, syntax, etc., and in many people's opinion (and mine), those differences makes it a different language.   I think I know what you meant about writing (ooRexx?) REXX programs that obey that subset, but the programs that I code are for Classic REXX and don't limit writing to a subset --- but I try to limit almost all my Rosetta Code REXX programs to what most Classic REXX programmers use (or know).   Of course there are exceptions, and they are noted when I code a REXX program for a particular Class REXX interpreter that has specific (additional) BIFs to accomplish a particular Rosetta Code task.   For Classic REXX programmers using/running (Microsoft) Windows on PeeCees, that usually means Regina REXX   (probably the most used, most common [free] REXX interpreter).   [I presume you meant writing/using ooRexx statements that obey that subset.]   Saying that, I'm in complete agreement with your third statement.   The minor disagreement with the 2nd statement is that there are subtle differences in the way Classic REXX and ooRexx treats, ... well, objects versus variables (or rather, their values), if you will, especially stems (possibly tail stems) and/or stemmed arrays --- (and I'm not an expert in ooRexx), but I'm recalling an acute discussion in a REXX newsgroup about this very issue where Classic REXX treats the assignment of a stemmed array (such as   a. = b.) differently than ooRexx (as I recall).   This was sometime ago and I don't recall the details.   ooRexx being what it is (object orientated), it's that way by design (and/or by definition).   The good news is that situation is an uncommon occurrence I should think (programming wise), and is therefore more of an academic discussion/exercise.   Having said that, somebody may point out the error of my assumptions. -- Gerard Schildberger (talk) 07:12, 26 July 2014 (UTC)

Please summarize your edits[edit]

Just a little note: when editing, it's polite to include something meaningful in the summary that says what you've done -- for example, if you add a new solution to a task, it's nice to put something like "added language" in the summary to let others know what you've done.

I'm still trying to get the hang of things. I'm not sure of I'm doing this correctly (where to reply/type this stuff). I find this type of "interaction" a bit strange and out-of-sync sort of feeling.

First, I don't even know where this summary thing is (was?) until just recently. Previously, I didn't know what it was for, as I was just adding new code (examples) and thought the adding of a new (code) example was self-explanatory. I'll try to add something like (added new example or some such) if that helps anyone understand what I just did. Hells bells, I don't even understand what I do half the time anyway. Hard to believe, but there are advantages of having senior moments.

Most of my updates (followups) are so minor that it would be distracting for casual readers what I've done, and I try to keep forcing my self to add comments to most of my REXX examples, something which seems might be a waste of time as I see very little evidence elsewhere of copious (or even brief) comments on (at) the statement level. I spend quite a bit of time dumbing-down my code to make it understandable for the novice (REXX) programmer. In doing so, I try to add (statement) comments on what the statements are doing/accomplishing, but the more advanced one gets, the more shortcuts one takes, and the code becomes obtuse with very little effort, sad to say.

REXX leads itself to writing a lot of "one-liner" subroutines (or, at the least, pretty short subroutines/procedures). This hides the commons tasks that happen over and over again, the duldrums of programming. The one-lines one-liners tend to end up at the bottom (end) of the program, usually after some kind of comment fence. Out of sight, out of mind. Most often, the one-lines are very general in nature and have been thourghly tested/debugged, and once written, almost never looked at again --- until Rosetta Code. Most REXX programmers write code on serveral classes of computers, PC's just being one. There is a lot of boilerplate to keep track of, environmental impacts, restrictions on command options, command names, command formats, terminal (console) support (linesize, screen width), fonts, file structure(s), file naming protocols, security concerns (read/write), operating system quirks (that's the polite word for it), etc, etc, etc. You wouldn'be believe the proglogue code that I have written (collected) over the ... ahem, decades of programming in REXX -- cough, cough, since around 1982 or so. And I'm a regular packrat. PL/I was way back in 1866 , er, make that 1966. Anywhooose, I'll try to make more summaries, even if almost all of them are quite bland and/or uninteresting. Gerard Schildberger

Under Special:Preferences is an option for the wiki to remind you to enter a summary if you forget; I highly recommend turning it on. (Look for "Prompt me when entering a blank edit summary" under the "Editing" tab.) -- Erik Siers 13:14, 29 October 2010 (UTC)

Hi Gerard, Adding the summary takes little time, and really helps others. Thanks. --Paddy3118 06:27, 30 October 2010 (UTC)

I'm not sure where these summaries end up, as I never had seen any. Is it under the "history" section? I must confess, when I look at some code, I don't care to read about how and/or when changes where made, all I care about is the final product (so to speak) and I'm not particuraly interestred in the code's change pedigree. But that's me, and I realize that others might find that sort of detail interesting in some way. Gerard Schildberger

The summaries do end up on the page history, but they also end up on Special:RecentChanges and in that page's RSS feed ( People like to keep an eye on the recent changes feed. Adding a summary there helps us decide if we need to check on an edit. Also you don't need to add a signature (--~~~~) in the summary. It doesn't get evaluated there (as you can probably see in the recent changes feed) and every place that the edit summary shows up already has your username and a timestamp attached to the edit. --Mwn3d 13:35, 25 April 2012 (UTC)


Welcome to Rosetta Code! I'm Mike, and I noticed you created an account.

Some quick things you should be aware of:

Template:Mylang Helps you show what languages you're familiar with, and helps us become aware of skills with languages we haven't seen.
Category:Unimplemented tasks by language A place to find tasks missing solutions in various languages.
Blogs, twitter, facebook... We have them, and are interested in yours.
Special:Webchat Logs you into #rosettacode on the Freenode IRC channel. Not usually the most active communications medium, but occasionally helpful. It's logged at
Rosetta Code:Village Pump A general Q/A and discussion area.
Rosetta Code:Finances For most of Rosetta Code's history, expenses have been paid out of my pocket. I can't afford that much longer, and so you can see the state of Rosetta Code's finances, and how you may help. If you enjoy or are excited about the site, please consider reading through it.

Sorry for the boilerplate; it can be a bit difficult giving an individual greeting to each person. If you post information about your technical interests and background, I'll probably read it. If you already have put that kind of information on your user page, I probably already have; I'm always interested in how people do and can benefit from Rosetta Code.--Michael Mol 12:31, 1 November 2010 (UTC)

Too much text on a page[edit]

Please try not to put more than a few KBs on a task page for each example. When the task pages get too large it gets difficult to manage. If you must add large examples or large output sections, please put them on a separate page and link them. --Mwn3d 03:57, 7 December 2010 (UTC)

If you really want to do a large Sierpinski triangle, do it as an image (no more than 800 pixels wide?) and use that. The code to do that instead of an ASCII version can be seen as an Extra Credit item, and it has the advantage of keeping the page much smaller. –Donal Fellows 09:36, 7 December 2010 (UTC)

I'm not sure I understand what you mean by as ASCII version. Are you referring to ASCII-7 bit? I often use extended ASCII (8 bits), code page 437, as that's the code page that the DOS prompt window uses (as well as the old DOS systems pre-Windows) --- at least, in the USA. I re-wrote the REXX program to use the ASCII-7 characters as a default, with support for the user to specify full ASCII-8 character codes.

I still haven't found out how to create another (separate) page to hold larger examples. I also have to learn how to link them. Gerard Schildberger

If you want to create a new page, simply type the intended title in the search bar on the left (you should probably do this in a new tab/window) and hit "Go". The page it takes you to will have a "create" tab at the top and (I think) a link somewhere in the text of the page that will let you create the page. From there, it's just like editing any other page. If you're creating a separate page for a large example or large output sample, you should keep the title of the new page to the form of "task title/language name" or something similar (if you get it wrong, someone will probably correct it). To link to that page (or any other page on the wiki) from the task page, put the title between two pairs of square brackets: [[Page title here]]. You can read up on all sorts of neat wiki tricks here. Also you can watch the Recent changes feed after you make edits to see what other people do to them (this is where the edit summary comes in handy). --Mwn3d 15:01, 8 December 2010 (UTC)

Request for dialogue[edit]

The text of an email sent to Gerard:

I was beginning to wonder what

[]   Watch this page

did     as I never got any notification(s) of any page watched. I've since learned that I had never entered an E-mail address (I had assummed that "it" would notify me when I logged on Rosetta Code). I never did like entering my E-mail address on a public forum, but ... I guess it is necessary for a diaglog in this forum. As a result, I'm desperately trying to play catchup and it's a bit overwhelming. Gerard Schildberger

My email, and response[edit]

Sorry Paddy; at the point where people start sending open letters, I figure it's time I finally take a look.

(I got permission to post the reply.) --Michael Mol 04:11, 8 December 2010 (UTC)

Gulp. I should've re-read my reply before I OKed it. Oh well, what's done is done. Water under the bridge, Split milk. Yesterday's news. Water over the dam. Yada, yada, yada.

I'm still in the midst of writing my general-purpose, nicer-slicer-dicer, all-in-one, one size fits all, money-back guaranteed (REXX) calculator (for a lack of a better word) program. It has over 1,225 functions in it, unlimited precision, supports plotting, histograms, many, many format of output. It runs almost anywhere and (for a few like-minded friends and myself), puts the recreation and fun back in recreational mathematics again.

I've found that quite a few of the tasks in Rosetta Code can be solved by a REXX routine (subroutine) that's in my "calculator". I rip out the code from the offending, er, REXX code, and, ahhhhh, the polite phrase would be to make it (more or less) readable to the novice programmer, and then add comments for most of the statements. At least, that's my story, and I'm sticking to it. I'm getting more and more lazy as I think adding comments to my code is like making a silk purse out of a sow's ear, and have become more lax in the addition of REXX statement comments. Gerard Schildberger

Ackermann function[edit]


There is a mistake in your Rexx code for Ackermann function (version 3). When m=4, the result is not a "double power", but a tetration, that is : ack(4, n) = 2 ^^ (n + 3) - 3 = 2^(2^(...^2)) - 3 when there are n + 3 occurrences of the number two in the power term.

For ack(4, 2), it's 2^2^2^2^2 - 3 = 2^65536 - 3, which is quite big, but manageable. For ack(4, 3), it would be 2^(2^65536) - 3, which is *too* big ! I let you imagine what ack(4, 15) should really be. ;-)

Thanks for the heads up. I fixed the Ackermann (version 3) example.

The ackerman(4,3) is ----- which, like ya said, is just too big.

The ackerman(4,15) is ----- for a total of times, and then subtract .

That's a pretty gihugeic number, if not gi-normous.
I don't think it'll fit in the known universe. -- Gerard Schildberger 20:33, 30 May 2012 (UTC)

Regarding Whitespace[edit]

You misunderstand the intent (and syntax) of the Whitespace programming language. Source code is composed solely of spaces, tabs, and newlines; flagging Whitespace solutions as missing source is silly. It's also rather odd that you seem to have singled the language out for missing output on tasks where many (if not most) solutions have also refrained from showing redundant output that would only serve to bloat the page.

Sorry, I didn't (or couldn't) see a source program (or tabs, newlines...). I was just about to change my flagging to reflect only the missing output, but you removed both reasons before I could correct it (removed the missing source part). I couldn't tell the blanks from blanks (the foreground from the background). I didn't single out that language for missing the output. It was the one that I noticed, I see nothing odd about noting missing output of the example that was just updated. I don't think showing three lines wouldn't add to bloat (especially when some examples show leading zeroes, and others don't), but that would be an interesting theory as to why some examples don't produce what the task asks for. As an aside, if people can't see (or read) the program, why show it? It may not be missing (maybe another way would be to say it isn't viewable), but could there be another way to render it on Rosetta Code? Further, if an example doesn't meet the task's requirements, does that make it eligible for flagging or not? If not, where is the "cutoff"? If yes, is there a burden on the flagger to mark all the other examples with similar afflictions? -- Gerard Schildberger 17:17, 18 March 2013 (UTC)
That you didn't (or couldn't) perceive any Whitespace source is very likely the fault of your browser; GeSHi supports Whitespace by displaying spaces on a blue background, tabs on pink. Perhaps I've misunderstood, and you're merely suggesting using S and T instead? Either way, a language's inscrutability shouldn't disqualify its otherwise valid solutions; very few people can "read" brainfuck in any meaningful sense, but I doubt you'd raise the same objection against it. I do understand that Whitespace is something of a "joke" language, but the fact of the matter is that its Turing-completeness alone should be sufficient to warrant its inclusion on the pages of Rosetta Code. It's also worth noting that I've taken the liberty of including pseudo-Assembly equivalents with all of my Whitespace solutions to more legibly illustrate what the code is doing. As for flagging for missing output, it seems the kind of thing that would best be served by common sense. Isopsephile 18:00, 18 March 2013 (UTC)
No, it wasn't the fault of my browser.   I normally view the (Classic) REXX examples (overwhelming my own, which means I'm looking at my own REXX code most of the time), the highlighting is horrible for the REXX language, especially in the way REXX comments are almost unreadable, especially when any type of arrow is used.   Also be aware that my REXX code is very heavily commented, most significantly sized programs have almost every line commented, and I don't feel that having almost unreadable comments is a good thing for highlighting to perform.   So, to fix that problem, I have highlighting disabled (as a default, but it can be toggled) and I live quite nicely without all the unnecessary colorization and comments being italicized (ugh! --- I should say, double ugh!).   The REXX language is a very minimalist language and is very easy to read.   So, being used to not having any code highlighted, I wasn't aware of the requirement that Whitespace   needs   highlighting to be "visible". -- Gerard Schildberger (talk) 23:07, 25 July 2014 (UTC)
(Yes, you misunderstood, I am NOT suggesting using what you described --- concerning the S and Ts.) I use Aurora (Firefox 21.0a2) for all my internet needs. I see that Firefox renders all of Whitespace programs as pure blanks on my system, while Microsoft's Internet Explorer shows "blocked" colors (for matters of privacy, speed, and such; I don't/won't use MS IE). So it appears that I would have to use MS IE to even view the Whitespace programs on Rosetta Code. I never had even thought of not including or excluding languages (because or lack of valid solutions or any other criteria, joke languages not withstanding). My (incorrect) flagging was based on lack of output as per the task's requirements (you had removed my incorrect flag in toto, and I was just about to remove the missing source part of the incorrect flag). I can understand your sensitivity to having one language example marked as incorrect while there are others also incorrect (missing output). That doesn't make it correct, however. Most likely, if somebody else marks the others as incorrect, the incorrect flags would probably just be removed anyway, with the same reasoning. I won't poke that hornet's nest again. Having a discussing about what is incorrect vs. correct, me thinks, in this context is a fruitless endeavor and probably nothing will be resolved. If missing output (as per the task's requirements) isn't incorrect, then will the flags that I've observed for (other) incorrect flags for missing output (in other Rosetta Code tasks) be removed or amended? Most likely not. -- Gerard Schildberger 18:49, 18 March 2013 (UTC)
I do not read the task as requiring the output to be shown, merely "produced" to some destination unspecified. The fact that the output is arbitrarily large only reinforces this interpretation, to my mind. --TimToady 19:00, 18 March 2013 (UTC)
I think it is good to add output if you can and it's not too long, or add a statement that the output is the same as for another language example if you must. Sadly a lot of contributors share the view that if there is any way of completing the letter of the task without showing output - then they will not show it.
Oh well. That's life :-)
--Paddy3118 19:20, 18 March 2013 (UTC)
For Binary digits: The task is to output the sequence of binary digits for a given non-negative integer.   Most programming examples used the three shoulds:   "The decimal value x should produce yyy ",   that's only three lines of output.   As for the Count in octal, the wording is certainly subject to interpretation: to produce a sequential count in octal, starting ... Each number should appear on a single line ... etc.   Now, if the task was to write a program THAT produces a sequential count ... but the difference is (very) subtle.   However, some of the examples DO NOT start at zero (as per the task's requirement), and if they did, some would show a blank (by suppressing all leading zeroes).   Again, I won't poke that hornet's nest, I'll leave it to others to flag those as incorrect.   I've used up my magic bullets.   We could on and on about the lack of output (and/or it's hugeness), if a program is incorrect (or not), and doesn't show (correct or incorrect) output. If no output is shown, then it most likely can't be flagged as incorrect.   I know enough of some languages, but not enough to start a "flagging" war.   It's like pushing a chain uphill.   I would hope that the programming examples on Rosetta Code would be exacting in that regard.   Once an incorrect program doesn't meet or complete a task's requirement(s), than other programs may follow suit (because nobody flagged it as incorrect), saying, "my output is the same as the other's output(s)", or somesuch words.   And so it goes. -- Gerard Schildberger 19:35, 18 March 2013 (UTC)
Another consideration is that for some tasks such as these, the output is Very Boring, and accomplishes little except to obscure the solutions. --TimToady 19:53, 18 March 2013 (UTC)
(I wish I had thought of that reason when completing exams.)   What about the incorrect solutions (regarding the output)?   If they hadn't provided output, I'd never noticed that they started with unity instead of zero.   It might be boring as boring can be, but it provides a way to catch (obvious) errors, even as something as simply counting in octal.   That's about as boring as it can get, and yet, still people get it wrong.   If they don't get flagged, they don't get corrected.   Those mistakes will still be there long after we're wormfood.   I know I'd like any of my mistakes pointed out, no matter how picayune. -- Gerard Schildberger 20:08, 18 March 2013 (UTC)
Now this:
(I wish I had thought of that reason when completing exams.)
Really made my morning :-)
Maybe we could adopt a "show some suitable output unless the task explicitly says not to" practice for a good RC example? --Paddy3118 04:34, 19 March 2013 (UTC)
That sounds like a great idea. Just peachy! -- Gerard Schildberger (talk) 23:10, 25 July 2014 (UTC)

REXX Long Multiplication[edit]

Sorry for the re-addition of the comment, but it doesn't really matter that REXX does its multiplication on decimal strings -- all languages with bignum supprt are doing the same thing too, they just happen to represent the numbers with some base that is bigger than 10 (sometimes much bigger), but the basic algorithm is exactly the same there as it is in REXX. Therefore, claiming that REXX already does this multiplication is something that could just as well apply to any of these other languages too.

--Elibarzilay (talk) 06:52, 13 May 2013 (UTC)

Well, you say I am claiming that it does, and you are claiming that it doesn't.   When you put it like that,
it sounds like my opinion is being impuned.   This is no place for a shouting match.   What do you
want me to do besides "claim" the facts?   By the way, not ALL languages with "bignum" support do it with a
a base bigger than 10.   REXX does not. -- Gerard Schildberger (talk) 07:14, 13 May 2013 (UTC)
Yes, I'm saying that not only REXX does it, *all* of the bignum libraries do it. The fact that some random library uses base 10 or base 256 or 65536 or whatever is irrelevant since the algorithm is the same for all of them, and re-implementing this algorithm is as bogus with any language as it is with REXX. The page seems like it requests an explicit implementation, regardless of bignum support or how its implemented, and if that's taken as is, then the REXX answer is wrong because it does not implement the algorithm. Like I said on the discussion page, I really don't care either way, but it should be clear which way it should go -- and if an implementation is required it is extremely unfair to single out about 3 solutions as broken when in fact many others on the page are broken. --Elibarzilay (talk) 07:48, 13 May 2013 (UTC)
No, REXX does explicit arithmetic   not   with BigNums, but with a method that people use when doing arithmetic on paper.   There is no base 10 in that the numbers are stored as characters, not a array of numbers in base 2, base 10, or possibly a higher base.   REXX does NOT perform arithmetic like any other langage (with the possible except of SNOBOL).   You just can't say that REXX does arithmetic like every language that has BigNum capability. -- Gerard Schildberger (talk) 08:01, 13 May 2013 (UTC)
It looks like you're not aware of how bignums are implemented: an arbitrary-length list of "digits". Operations are implemented in terms of these lists. Usually, the digits are big with each one being a machine word. But it doesn't matter if you use a smaller base-10, everything works the same, and the resulting algorithm *is* what you would do on paper.
But all of this is irrelevant: they asked for an explicit implementation of unlimited integers, and using a library means that you don't do what they asked. The way which the REXX implementation does things is irrelevant to such an implementation, or the lack of such an implementation. --Elibarzilay (talk) 08:43, 13 May 2013 (UTC)

Er, no.   REXX does arithmetic on characters (which just happen to be digits, just as people do on paper.
REXX is the only language (except for possible SNOBOL) that does this.
Other languages using BigNum (or extended precision) support work on binary representation of decimal digits,
not characters.   Please note that decimal strings are not the same as character strings, but sometimes
I use them interchangeably to make it easier to comprehend.   I had a very long discussion on this very subject
a while back before it was clear that REXX doesn't store numbers, just characters.   This came up when
I tried to explain that the internal (ASCII) representation of 37 is '3337'x   (or '37'c) -- with a length of two
characters (exactly). -- Gerard Schildberger (talk) 07:07, 13 May 2013 (UTC)

This is also not relevant, since the algorithm itself is the same, whether done with decimal digits or another base, whether represented as ASCII numerals or plain numbers, and whether stored in RAM or on printed paper. And since its the same, any of these languages with bignums should be able to have just the quick multiplication as a solution. --Elibarzilay (talk) 07:51, 13 May 2013 (UTC)
Er, no again.   The algorithm (doing multiplication on paper) is not the same as what is done (with computers using BigNum) with binary diginits, decimal digits, or higher bases.   The BigNum algorithm is not a mimic of pencil arithmetic, to coin a phrase. -- Gerard Schildberger (talk) 08:06, 13 May 2013 (UTC)

Discussion moved from task page[edit]

Hi, I just moved your discussion from the task page. It may need cleanup. We don't normally have such discussions on the task page. --Paddy3118 (talk) 10:05, 8 June 2013 (UTC)

Yes, I was considering flagging it incorrect, but as there's a lot of "investment" and/or "ownership" (signed work) involved, it fastly dissolves into a discussion about opinions, with rationalizations and then, even more questions about the questions.   If incorrect statements are made in the section header (and/or trailer), is an off-page rebuttal/correction the way to go?   Normally, I would expect the incorrect statement to be corrected, but then it gets into a situation of who is correct in correcting the incorrect statement(s)?   Normally, there isn't that much preaching done in section headers, saying things like this version doesn't need to use what the previous version used, so this one is (implied) better.   Or, this version works with all REXXs, (but clearly doesn't).   Putting a rebuttal elsewhere isn't very topical. -- Gerard Schildberger (talk) 00:43, 9 June 2013 (UTC)
  I don't believe in adding versions (of the same language) that do less, and with restrictions that make the solution incorrect.   And so it goes. -- Gerard Schildberger (talk) 00:43, 9 June 2013 (UTC)

Ironclad programming language[edit]

I've noticed that you've added the "Ironclad" programming language. Do you have more information about it? The only thing a quick web search turned up is "Ironclad C++", a type-safe subset of C++. Is that the language you mean?

I have no info about it except that Ironclad was used several times in the header statement (as a language) and I had entered it as a language in the Ironclad entry;   the entry was missing the language tag.   Not added the tag would mean that some lists wouldn't be maintained, nor would the language be counted elsewhere (such as code popularity). -- Gerard Schildberger (talk) 19:42, 26 February 2014 (UTC)
I have used Ironclad with Template:libheader which indicates the libraries used in the code.--Andreas Perstinger (talk) 21:44, 26 February 2014 (UTC)

The reason why I ask is that just a few days ago I've added the Ironclad library for Common Lisp. So we now have a nameclash. I will move the library to [[Category:Ironclad (library)]] if both names are really equal.--Andreas Perstinger (talk) 19:21, 26 February 2014 (UTC)

Since I don't know the difference between the Ironclad language and the Ironclad library, perhaps someone with more knowledge can address this issue.   Any "damage" done at this point can easily be undone. -- Gerard Schildberger (talk) 19:42, 26 February 2014 (UTC)
Ok, I have removed {{language}} from Category:Ironclad since it looks like there is no language Ironclad.--Andreas Perstinger (talk) 21:44, 26 February 2014 (UTC)
If   Ironclad   isn't a language, then why was it used in the     {{header|Ironclad}}     tags?   What follows the     header|     is supposed to be a language (as far as I know).   The   Category Page   is meant for create a page for the language.   This is what I read from the documentation on the   Add a Language   page. -- Gerard Schildberger (talk) 22:17, 26 February 2014 (UTC)
Where have you seen that it was used with Template:header?--Andreas Perstinger (talk) 22:46, 26 February 2014 (UTC)
I can't find any now, they're all using LIBRARY.   I am a bit befuddled as I may have confused it with the Shen and Coco entries when I was doing the searching for language orphans.   Sorry for the confusion and wasting your time. -- Gerard Schildberger (talk) 23:06, 26 February 2014 (UTC)

P.S.: I'm in the process of finding language orphans and adding a   category:xxx   and   xxx   page for them.   The only bona fide I'm using (more of an assumption than anything) is the fact that   xxx   was used as a language in the   header   tag. -- Gerard Schildberger (talk) 19:42, 26 February 2014 (UTC)

If you add a language page in the main namespace (i.e. not a category page), you should just redirect to the category page (see Rosetta_Code:Add_a_Language#Redirect).--Andreas Perstinger (talk) 21:44, 26 February 2014 (UTC)
Yup, I missed that step. -- Gerard Schildberger (talk) 22:17, 26 February 2014 (UTC)

Tildes in edit summaries[edit]

~~~~ doesn't work in edit summaries. Fortunately, it's unnecessary. Take a look at Special:RecentChanges or a specific page's history and you can see that every edit's author shows up automatically, while your tildes remain tildes. —Underscore (Talk) 01:44, 27 February 2014 (UTC)

Check edits to: Quaternion type[edit]

Hi, some of your edits to the page left equations that would not parse and show as glaring red errors. Could you review you edits please and fix the page.
Thanks. --Paddy3118 (talk) 22:42, 2 August 2016 (UTC)

The edit that I did just used the   <big>   HTML tag around the   <math>   HTML tag   (to make the mathematical symbols easier to read).       After reviewing my editing, there wasn't any problem displaying the (bigger)   <math>   HTML tag.   I know (that is, I heard from others) the   <math>   HTML tag has been causing problems (apparently) with some newer updates to browsers or other rendering agents   (I'm not an expert in exactly   where   the error occurs, but my FireFox (Aurora) browser and my ancient Microsoft Internet Explorer didn't/doesn't have problems rendering my (bigger math) edits.   -- Gerard Schildberger (talk) 01:55, 3 August 2016 (UTC)

Hi Gerard. It is a bug specific to browsers (all on windows 10):

  • Chrome, (my default browser): BIG RED LETTERS around the norm of a quaternion equation from the task description, saying it cannot parse it.
  • Edge, (I don't use it usually): the norm equation is a blank box!
  • Firefox, (my alternate browser of choice): Displays the norm equation perfectly!

Maybe you could experiment with the section and see what displays in Chrome too?

Chrome is: Version 52.0.2743.82 m (64-bit).

Thanks, --Paddy3118 (talk) 06:13, 3 August 2016 (UTC)

My PeeCee (for the internet) is running Windows/XP and at this point, it is pretty hard (or next to impossible) to install new software.   I have yet to install the latest FireFox (amongst other things).   My Microsoft Internet Explorer is at Version 8.0, so I'm looking at an uphill battle.   I always figured that if older versions (when rendering HTML code) work, then the newer stuff should also work.   Obviously, that belief is wrong.   I'm quite surprised that this problem (with rendering   <math>   HTML tag   stuff with   <big>   HTML tag)   would've been fixed by now.   My other car is a Rolls.   Er, I mean, my other PeeCee is running Windows 7, but it is an air-gap computer   (no internet connection).   -- Gerard Schildberger (talk) 07:12, 3 August 2016 (UTC)
Well, I also put in a report to the Google chrome guys, but they state they may not even answer! --Paddy3118 (talk) 15:31, 3 August 2016 (UTC)
Uf-ta.   That sure is a bummer when the Google guys may not even acknowledge the problem and/or your reporting of same.   -- Gerard Schildberger (talk) 19:25, 3 August 2016 (UTC)

Range extraction/Format: Spaces are significant[edit]

Hi, The absence of spaces in the description of the format is most significant so I had to revert your edit. It is good to tidy things up, but you need to thoroughly understand some of these task descriptions before contemplating changes to ensure any change made does not alter the task. In this case you confused the task description - the text described one thing - your changed example introduced spaces.

I used one blank before the lists to cause a shaded window for the (comma separated) lists.   The revert re-introduced an indentation character (:) which produces an indentation of five spaces, which causes more whitespace (but without shading).   I don't see where the task (description) was altered to have a different meaning.   No mention of whitespace (blanks) was used in the description.   It just mentions comma-separated "lists".   I had no intention to tidy up the task, the change was to make the lists more visually identifiable by using a shaded box.   -- Gerard Schildberger (talk) 08:40, 4 August 2016 (UTC)

I do think it is good to tidy up tasks. Thanks for doing it - it is appreciated. (I just thought I'd let you know of this issue :-)

--Paddy3118 (talk) 07:09, 4 August 2016 (UTC)

Leading and trailing spaces in <math> tags contents makes formulae invisible in OS X Safari & Chrome[edit]

Hi Gerard - a quick heads up that in some task-spec tidying you have introduced a single white space character at the start and/or end of various <math> tag contents, and it seems to be this that has recently been rendering formulae invisible in OSX browsers. Simply deleting the flanking spaces turns out to restore visibility for browsers on this platform. Hout (talk) 19:20, 15 September 2016 (UTC)

No L in Gerard.
If a simple blank (whitespace) causes some   <math>   stuff to be rendered invisible, have you considered that there is an error in the OS X browsers?   I only occasionally use Microsoft IE, and (almost always) FireFox, and this is want I use to test rendering.   Have you notified/reported this problem to those browsers that they're failing?   I suspect that it would be simple thing to fix;   HTML rendering is   (for the most part)   whitespace tolerant.   Also note that introduction of whitespace within   <math>   content is simply ignored   (or rather, it's supposed to be ignored).   If not, the   <math>   support/code should be fixed, it could be systematic of a failing in other parts of that code that we're not aware of.   -- Gerard Schildberger (talk) 19:44, 15 September 2016 (UTC)
White space within the content is fine. The problem (all math content rendered entirely invisible) arises from the edits which have recently introduced it before and after the printable characters. Pending any possible changes in browser behaviour, it would seem helpful to reverse that aspect of the edits.
I agree in part.   The rendering problem arises from the inability of some browsers (that are in error in this respect) to not render whitespace correctly (or maybe in better wording, to not ignore/process whitespace correctly).   But I agree with you in that removing that particular whitespace at this point (until the   <math>   support/code is fixed) would be the prudent short-fix.   Have you identified that it is the leading whitespace within   <math>   and/or the trailing whitespace?   Also, can you give me some sort of tracking/bug number so I can follow the fixing/addressing of this browser bug?   -- Gerard Schildberger (talk) 20:08, 15 September 2016 (UTC)
Introducing either a trailing or a leading white space results in the generation of html (from the space-flanked Latex expression) which does not display any formulae in Chrome or Safari on OS X. The existence of parallel bugs in Chrome and Safari is one hypothesis. Another would be that the the problem lies in the wiki software process which generates HTML code from the Latex expression. One would need to look at the difference between the HTML generated from plain and space-flanked Latex expressions. Hout (talk) 20:16, 15 September 2016 (UTC)
I'm nowhere near being an expert in the ins-and-outs of generating HTML code --- (within Wiki, in this case, and furthermore, within the Rosetta Code Wiki, and futhermoreso, within particular, newer, fancy-dancy browsers).   Are we (you and I) using the same Wiki "code" (as regards to Rosetta Code)?   Is it the generating of the HTML code different, or the rendering of the code different (for the failing browsers)? --- (Or possibly both?)   I don't expect an answer (or even being educated to the point of trying to help debug the problem), as I probably wouldn't understand the difference, nor appreciate the subtleties of trying to determine where the bug actually lies.   -- Gerard Schildberger (talk) 20:31, 15 September 2016 (UTC)
I guess another thing that seems a little unclear is whether it's actually standards-compliant or syntactically meaningful to flank the Tex expression with white spaces. I notice that none of the examples here do that: .
You will have a better idea than I of what value you sought to add by introducing them. (My understanding is that white space literals are not the Latex encoding of additional white space, for example). Hout (talk) 20:42, 15 September 2016 (UTC)
One of the first examples I saw (elsewhere) was:
          <math> ... </math>  
Since whitespace is optional, (most) examples wouldn't show any optional whitespace, as it isn't syntactically meaningful. (Just as the fifty blanks after this clause, see the original text via the EDIT verb).   If it where not standard-compliant, the standard would've mentioned that whitespace was NOT allowed, but nowhere does it mention that or even hinted at.   And, yes, I do have a better idea of what value I thought there was when I added more whitespace.   It was to simply make it easier for me to read and then update/edit the HTML (markup) code (not the rendered code), especially where there is a lot of text and/or marked-up (general) text, and a little bit of whitespace made it easier for me to grasp the start and stop of the   <math>   code, particularly if there is other HTML tags.   -- Gerard Schildberger (talk) 01:28, 16 September 2016 (UTC)
Well, you say "Since whitespace is optional ...", but where ? In what specific context is it optional ? HTML ? Latex ? The Wiki software's Latex-to-HTML preprocessor ? The technical contexts for that statement are rather ill-defined. The context that really matters, and of which we do have a clear picture, is that of the value for users. Experiment is showing us clearly and unambiguously that in that context the whitespace is not "optional" – introducing it creates no value for any users, but it does entirely remove formula visibility for significant numbers of users. Hout (talk) 14:37, 16 September 2016 (UTC)
Just to add to the puzzle, with Firefox a formula expression preceded or followed by a space (as exemplified above) evokes a garbled complaint in startling big red letters: (I've removed the text of the formula from the end)
Failed to parse (MathML with SVG or PNG fallback (recommended for modern browsers and accessibility tools): Invalid response ("<p>There was a problem during the HTTP request: 502 Bad Gateway </p>") from server "":):
Without such spaces, Firefox renders the formula, but other browsers don't. Other web pages seem to employ an image file, or a collection of images of symbols to obtain a pleasing result. If I understand matters correctly, the RC system sends (or could send) different .html stuff according to the name of the browser it is feeding, so, I'm well adrift. Dinosaur (talk) 11:57, 17 November 2017 (UTC)

Restoring formula visibility to 50+ tasks for Chrome, IE/Edge, Safari etc[edit]

Hi Gerard, as it has emerged that the loss of formula visibility has not been platform-specific, and, as you mentioned that you did have one of the majority-type browsers installed (Internet Explorer), as well as one of the minority-type (FireFox), you should be able to fix your edits to restore formula visibility by testing their effects in IE.

The list of tasks in which formula visibility still needs to be restored is below. You will find that on the discussion page of each affected task I have indicated the exact time and day of the edit which removed visibility. Not all of those are your edits, but I think you may find that about 50 of them are.

The underlying problem is that current browsers use two different approaches to displaying formulae, and the WikiMedia generator has to generate separate code for each.
It will never be safe or prudent to make formula edits in one class of browser without checking their real effects in the other class. Firefox is particularly ill-suited for use as the main vehicle of formula edits, as it is in the minority class which uses MathML and depends on local fonts. (It provides no indication of how the server-side formula graphic is displaying).
Better to edit formulae mainly with one of the majority class (Chrome, IE/Edge, Safari etc. which display the server-side graphic file), and then check the results in Firefox too. Hout (talk) 10:07, 26 September 2016 (UTC) (Repaired by Hout 1 November 2016) (Repaired by WillNess 25 September 2016) (Repaired by Hout 22 October 2016) (Repaired by Hout 3 November 2016) (Repaired by Hout 18 October 2016) (Repaired by Bmulvey 18 October 2016) (Repaired by Hout 16 November 2016) (Repaired by Hout 16 November 2016) (Repaired by Hout 26 September 2016) (Repaired by Hout 26 October 2016) (Repaired by Hout 21 November 2016) (Repaired by Hout 14 November 2016) (Repaired by TobyK 7 Nov 2016) (Repaired by WillNess 15 October 2016) (Repaired by Hout 21 November 2016) (Repaired by Hout 16 November 2016) (Repaired by Hout 21 November 2016) (Repaired by Bmulvey 15 October 2016) (Repaired by Hout 21 November 2016) (Repaired byHout 17 October 2016) (Repaired by WillNess 15 October 2016) (Repaired by Hout 16 October 2016) (Repaired by Hout 9 November 2016) (Repaired by Hout 16 November 2016) (Visibility restored by Hout 20 November 2016) (Repaired by Hout 13 November 2016) (Repaired by Hout 20 October 2016) (Repaired by Tikkanz 25 September 2016) (Repaired by Hout 26 September 2016) (Repaired by Hout 21 November 2016) (Repaired by Hout 13 November 2016) (Repaired by Hout 27 September 2016) (Repaired by Paddy3118 28 October 2016) (Repaired by Hout 15 November 2016) (Repaired by Hout 26 Oct 2016) (Repaired by Hout 21 November 2016) (Repaired by Hout 11 October 2016) (Repaired by Hout 16 November 2016) (Repaired by Hout 7 Oct 2016) (Repaired by Hout 4 Oct 2016) (Repaired by Hout 3 November 2016) (Repaired by Hout 13 November 2016) (Repaired by Hout 24 November 2016) (Repaired by Hout 15 October 2016) (Repaired by Hout 9 November 2016) (Repaired by Hout 10 November 2016) (Repaired by Hout 22 November 2016) (Repaired by Hout 10 November 2016) (Repaired by Hout 21 November 2016) (Number set symbols now made visible Hout (talk) 21:56, 3 December 2016 (UTC)) (Repaired by Hout 28 September 2016) (Repaired by Hout 15 November 2016)

Updated to record two formula visibility repairs Hout (talk) 18:49, 25 September 2016 (UTC)
Updated to record one more repair on 1 Oct 2016. 50 tasks have still not recovered the visibility of their formulae.
Updated to record two more repairs on Oct 9 2016 - 48 task repairs still outstanding. Hout (talk) 22:28, 9 October 2016 (UTC)
Ragged manual spacing, and exaggerated disparities of relative font sizes, still add friction to the reading of others. Hout (talk) 21:06, 1 October 2016 (UTC)
It would also be very helpful, when restoring the lost display of server-side formula graphics, to repair the excessive disparity between text size and formula size which was often introduced, as part of these under-tested cosmetic edits, by a practice of enclosing formulae in a doubled pair of <big> tags.
The use of <big> tags is not an intended or appropriate way of increasing the absolute size of formulae - that should be done with the browser's Zoom function. The role of <big> tags is to change relative differences in text size.
Doubled application of these tags simply creates an excessive and visually uncomfortable disparity of scale between text and formula on many, if not all, browsers. Hout (talk) 14:13, 26 September 2016 (UTC)
Updated the list of tasks repaired or awaiting repair:
3 task descriptions still need repair (to restore the lost visibility of their formulae)
3 user contributions include graphics which are invisible to Chrome IE/Edge Safari Opera and the majority of other browsers. Hout (talk) 20:11, 22 November 2016 (UTC)
The restoration of all the task description formulae inadvertently made invisible by Gerard's heroic and protracted campaign of cosmetic edits is now complete. (Come back Gerard - all is forgiven !) :-)
All that remains is an obdurate residue of intractable cases where formulae have been invisible from the beginning, and were not affected by the cosmetic edits campaign:
Cases where formulae remain invisible to the majority of browsers, including Chrome, IE/Edge, Safari, Opera etc, but may, subject to the installation of requisite fonts, prove visible in Firefox:
  1. The norm of a quarternion in (an explanatory note has been added)
  2. The number set symbols in (perhaps these could just be changed to the bold capitals N Z Q C etc. ?)
  3. Three uses of formulae in preambles to language-specific contributions:
I will periodically (maybe once a month ?) run an HTML scan to pick up any newly invisible cases. Invisible graphic elements (server-side formula graphics) can be detected by searching through the wiki-generated HTML for the pathological string "exheight" – an undelimited conflation of two attribute names, which leaves the affected graphic with zero height. Hout (talk) 11:13, 25 November 2016 (UTC)
The moral of this sad episode is that FireFox is out on a limb in its handling of <math> tags – they do things differently there.
(Local font-based MathML processing, rather than the usual font-independent display of server-side formula graphics).
Previewing <math> tag contents in Firefox gives no indication of how things really appear on the majority of browsers. If you do edit in Firefox, you must always also check the real effects of your edit in either Chrome, IE/Edge, Safari, or Opera.
Any one of them will do. Hout (talk) 11:24, 25 November 2016 (UTC)


I've fixed Commatizing_numbers#Phix. Thanks for the mild slap - it wasn't exactly my best effort, now was it? Pete Lomax (talk) 22:42, 7 April 2017 (UTC)

I didn't mean my comments to be a slap, just a nudge to fulfill the task's requirements.   After any changes/enhancements are done, the "incomplete flag" can be deleted, and all waters are calm.   But thank you for completing/fulfilling all of the task's requirements (and having a sense of humor).   -- Gerard Schildberger (talk) 00:14, 8 April 2017 (UTC)

RC POP.OUT[edit]

Thanks for the updates!

I've been wondering whether some languages should be grouped, specifically whether the variants of Algol 68, Algol W, Algol 60, and Algol could be unified. Not so that each solution counts, only that one or more for a given task counts as one. But aside from the complications of doing so, I suppose they could be regarded as sufficiently different to be counted separately. Just as with the various languages involving the word "Basic" - which one imagines are basically similar too. Then there are the variations on C.

Oh well, maybe not. Thanks for the updates anyway. Dinosaur (talk) 11:47, 30 May 2017 (UTC)

Humm. When a language gains another task's solution, it would be interesting for your schedule to name the task (or tasks), even with a link to the task... One does wonder just which tasks have now been solved. Given that the solutions for a given task are occasionally out of order (or possibly not in the strict character collating order) some caution would be required. Dinosaur (talk) 10:50, 17 November 2017 (UTC)

KPBF sample[edit]

Gerard: u got it wrong!

Task: using n times self-product of the matrix (filled with 0/1) we will have a fractal of the n-th order.

In your REXX case it means: aMat x aMat x aMat x aMat x ... and bMat x bMat x bMat x bMat x ...

Check all other languages, some of them have even links to images. All the best 2u! --AnatolV 23:17, 27 May 2017 (UTC)

The   Kronecker product based fractals   REXX entry was fixed on June 10th, 2017.   -- Gerard Schildberger (talk) 05:10, 7 September 2017 (UTC)

RC POP.OUT, differences[edit]


I have a different output with Stata (see Rosetta Code/Rank languages by popularity), which may indicate a bug in my program that I would like to investigate. Could you give the output for the language file? I get only 671 languages, while you find 685 ones. Also, I find only 650 languages with at leat one entry, while you find 651 ones. However, your list has only 650 languages, so it's a bit puzzling.

I have also differences in this list: SETL4 and FORTRAN don't appear in the Category:Programming Languages page, but you seem to have entries for them. This should not happen, even though there are actually tasks for these "non-languages", for instance Sorting Algorithms/Circle Sort#FORTRAN: it should not happen because the language appears in red, since the page does not exist, so the page should be corrected. On the other hand, you don't have the Fortran and Setl4 languages, which exist. There are more annoying problems in your list, for instance you don't seem to have Category:உயிர்/Uyir, nor Category:Déjà Vu (you have Déjá Vu, which is incorrect, the accent should be the other way around).

Eoraptor (talk) 20:36, 3 December 2017 (UTC)

I just re-ran my REXX program and updated the RC_POP.OUT file (here on Rosetta Code).   I don't know where you found that my list (REXX) has only 650 languages.   From the data posted to Rosetta Code (from my REXX execution), it shows 651 entries, as well as my count from looking/counting languages from the original file on my computer.   When you say "your list has only 650", how (and where) did you determine that?   -- Gerard Schildberger (talk) 05:04, 4 December 2017 (UTC)
There are 650 rows in the table in the version of November 17th here. I copy-pasted into Notepad++, there are 650 rows, period. Now that you have revised the list, there are 651 languages. I can also tell you the difference between the two lists: 646 languages are identical, and for the remaining, the older one has Déjá Vu, FORTRAN, N/t/roff, Spin, while the newer one has Blast, Déjà Vu, Fortran, ML, Panoramic. Eoraptor (talk) 08:04, 4 December 2017 (UTC)
Before I updated the REXX's output file, I looked at the (original) OUTPUT source (for November 17th, 2017)   and verified that there was 651 programming languages.   Now, it is possible that I made a cut-'n-paste finger flub (that ended up with 650 entries on Rosetta Code).   -- Gerard Schildberger (talk) 10:49, 4 December 2017 (UTC)
As for SETL4 and FORTRAN appearing in my list, my REXX program ignores and differences in capitalization of the languages on Rosetta Code.   Because some languages appear in different spellings (as far as capitalization), I use the first spelling that was encountered in the input file.   So, that means, somewhere in the Rosetta Code   tasks   and/or   draft tasks,   there is   a   language entry (example) that has Fortran spelled as FORTRAN.   The same with SETL4.   Ditto for Déjá Vu and others.   A few years ago (2012), I entered a new discussion page   case of names of programming languages   for the task Rosetta Code/Rank languages by popularity.   I had noticed that some computer programming languages has various spellings, either via different capitalizations, or by different accent characters, or in some cases, different characters, such as using the Greek character   µ   in   µC++,   some people used the extended ASCII character (probably from DOS code page 437 or equivalent), other people used the Unicode character.   I translated Unicode characters to what my REXX program was using, DOS code page 437.   This was especially problematic with   Déjá Vu,   where (various) different accent characters where used.   Two programming languages (Caché, MK-61/52, and Uyir) were (wholly or in part) entered in Unicode, and I had to translate those to Latin characters so that I could handle them in my REXX program.   I asked for clarification (in that discussion section), but nobody followed up, and as far as I could tell, hardly any misspellings were corrected with the exception of PL/I.   I have said (posted) previously, that I am not the spelling police for computer programming languages   (except for REXX, which I laboriously tracked down and corrected).   For a followup on this, see the source for the language entry REXX on the task page for   Rosetta Code/Rank languages by popularity.   Because I didn't know (for the most part) the correct (or official) spellings for any computer programming language, I elected to capitalized all computer programming languages, and just use the first computer programming language spelling encountered as the version used in the REXX program's output.   Some spellings for programming languages have changed over the years, FORTRAN being one of them.   Other misspellings are sometimes obvious, but I did not want to handle the various spellings on a case-by-case basis, and elected to follow the motto,   first come, first served   (that is, use the first spelling version as the one used in the REXX program's output).   By the way,   Uyir   is   listed in the REXX output, it's ranked at 509 (tied) with 3 entries (as of this writing).   As for   Déjà Vu,   I'll change the REXX program to use the correct accent character.   -- Gerard Schildberger (talk) 05:04, 4 December 2017 (UTC)
It's not about being a "spelling police". Rosetta Code titles are case-dependent, so it may happen that two pages have the same name with a different spelling. And it does happen, with categories not having the same number of members. Actually FORTRAN was not even a registered category, it's a mistake by some Rosetta Code user: a language entry written with FORTRAN, which has a red link since the category was not created, but which still appears in category lists (a kind of bug of the wikicode I guess, I believe I have seen this on Wikipedia too). Since your list is given as a reference for the task, it should be as correct as possible. I was not aware of this Unicode problem with REXX, but it puzzles me to use for reference a language that is not able to spell the languages correctly. How one is expected to check his own output then?
The µC++ example is interesting: I initially thought I had a bug, because it's spelled ΜC++ in my output. However, it's really a greek uppercase Mu. I simply took the name in the link, which is always capitalized, and not the screen name, which is sometimes different. While Μ and M are visually identical, they are different Unicode characters (924 and 77 respectively).
Eoraptor (talk) 08:04, 4 December 2017 (UTC)
Nowhere in the REXX program is there an enforcement of the correct spelling, nor is any determination attempted for that matter.   At the time, the REXX code (that I entered, version 1) honored the spelling as per the capitalization, and then later, I changed the REXX code to ignore the capitalization and use whatever spelling was first encountered in the appropriate Wiki file.   Later, I added transformations of Unicode characters that were translated in the best manner possible to Latin characters or to various accented characters (letters?) that were included in (DOS) code page 437.   This was a close to being "correct" as possible within what was available within the specifications of the code page that was being used with/for REXX at that time.   I had assumed that if a reader observed an entry for FORTRAN or Fortran, they would assume it was the same computer programming language.   Programming languages entered as Unicode   and   also ASCII are problematic, and I built a hand-coded list of a translate table between the two.   This translation is further complicated when some programming languages use   different   alphabets for the same language   (or different Unicode characters, for that matter).   It is these situations that I was alluding to when I used the phrase   spelling police.   If there isn't a common (accepted by all) spelling of a computer programming language, it would be a never-ending job to have a   correct   list.   Whether or not that REXX can't handle Unicode characters, how would one handle the situation when different Unicode characters are specified?   I tried to do the best I could with the limitations of not being able to use Unicode characters within the REXX language (when storing literals).   Keep in mind that I coded the REXX entry to provide a complete list, as at that time, I couldn't observe what the ranking was for the REXX language as nobody had shown a ranking of computer programming languages on Rosetta Code that went beyond (the top) 15 entries.   If someone had shown a complete listing, these "misspelling" errors might've/would've been addressed (or even resolved/fixed) at a much earlier time   (and there wouldn't be a REXX entry).   But, to answer your query about checking one's output when the languages aren't correctly spelled, I would suggest that most of the time, it's a matter of capitalization.   If the spelling error is more dramatic, then use the closest spelling that conveys the name of the programming language as the reference.   Aside from all that, I'll entertain any suggestions that would solve or address this issue within the confines of the REXX language.   -- Gerard Schildberger (talk) 10:49, 4 December 2017 (UTC)

I just re-checked about the (correct) spelling of the computer programming language   Déjà Vu,   and it is indeed misspelled almost everywhere on Rosetta Code   (as   Déjá Vu).   Should someone with the proper administrative authority do a global change to reflect the proper spelling?   -- Gerard Schildberger (talk) 12:03, 4 December 2017 (UTC)

Are you sure? I don't see any instance in Special:Categories&limit=5000 (caution: large page). And since the major contributor for this language on RC seems to be its author (see this and compare to this), I guess he takes care to spell it correctly. Eoraptor (talk) 12:05, 8 December 2017 (UTC)

I finally got to the root of the problem --- it was my misunderstanding/misreading/misinterpreting of the (or a ?) translation of two files that I had downloaded from Rosetta Code.   It finally became clear to me that we were observing the same character as two   different   characters, even though they were the same ··· err, I hope that almost makes sense.   The ASCII files that I was viewing:

RC_POP.LAN              Line=919   Col=1   Size=918  Alt=0,0;1
    * * * Top of File * * *
    ------------------------------- 262 line(s) not displayed ----------------------
      * Déjà Vu </wiki/Category:D%C3%A9j%C3%A0_Vu>
    ------------------------------- 655 line(s) not displayed ----------------------
    * * * End of File * * *


RC_POP.CAT              Line=1125  Col=1   Size=4818 Alt=0,0;2
    * * * Top of File * * *
    ------------------------------- 1123 line(s) not displayed ---------------------
      * Déjà Vu </wiki/Category:D%C3%A9j%C3%A0_Vu>‏‎ (105 members)
      * Déjà Vu/Omit </wiki/Category:D%C3%A9j%C3%A0_Vu/Omit>‏‎ (6 members)
      * Déjà Vu Implementations
    -------------------------------- 2 line(s) not displayed -----------------------
      * Déjà Vu User
    -------------------------------- 2 line(s) not displayed -----------------------
      * Déjà Vu examples needing attention
    -------------------------------- 2 line(s) not displayed -----------------------
      * Déjà Vu related
    ------------------------------- 3683 line(s) not displayed ---------------------

where I was interpreting:

  the 1st character     D   (ASCII)    as  capital    D
  the 2nd character(s)  ├⌐  (Unicode)  as  lowercase  é
  the 3rd character     j   (ASCII)    as  lowercase  j
  the 4th character(s)  ├á  (Unicode)  as  lowercase  á

You can see where where I made the assumption that   ├á   was the ASCII character   á       (instead of the correct character   à).   I'll will correct the translation within my REXX program and also the program's output.   (Pardon my French, but that was a bugger to track down).   -- Gerard Schildberger (talk) 16:55, 10 December 2017 (UTC)

I see. If you open a file encoded in UTF-8 in a editor that tries to interpret it as another codepage, you will get that kind of problem. For instance, "Déjà" is printed as "D├⌐j├á vu" in CP437 (a DOS codepage, that you seem to be using here), or "DéjÃ" in ISO-8859-1 (Latin-1). That's because UTF-8 encodes Unicode characters as multibyte sequences. It would be possible to read a UTF-8 as binary and do the translation "by hand", but there are programs able to do the translation for you. On Windows, the Notepad++ text editor can do this. Eoraptor (talk) 10:18, 11 December 2017 (UTC)