In article <[EMAIL PROTECTED]>, Lars Henrik Mathiesen <[EMAIL PROTECTED]> writes: > Well, people actually managed to input the other strange chars in > their browser: tabs, �, and so on. But for NUL, Dave would have had to > change every submission manually in PGAS --- that's the main reason. > Since it was the same for everyone, the competition was still fair.
I disagree slightly. It was unfair to people who had thought of using \0. It was only fair inside the group of people using \0. And then only if they used it equally often. E.g. someone not thinking of v0 x3 in constructing a literal value looses one stroke on "\0"x3 > > Now if some golfer had had the time to fake up the HTTP and submit > with a NUL, we would have had to think of something. My first idea > would have been to let the scoring subtract one for every occurence of > \0, for this course only, and come up with something better for the > next. If only I'd known, I'd have done exactly that. but I had understood that binary 0 would in fact be simply refused. > > Now we actually had some sightings of the CR/NL issue as well, with > some submissions that only worked in Linux if I stripped ^M from the > ends of lines inside strings, and one other that only worked if I > _left_ the ^M on the end of the flags line. The latter problem quickly > disappeared as the submitter changed his method, but both point to a > possible Windows/Linux incompatibility. > Actually it's a browser bug. newlines in text fields MUST be sent as cr/lf. It's in the standard. So if you want to send cr newline, the browser should transmit it as cr cr lf, and the server should convert the end cr lf back to logical newline (ending up with cr \n). > So to be complete, the rules should specify whether solutions will be > tested as submitted on either platform (i.e., with \r\n if pasted into > a textarea, or exactly as sent by file input) or with 'canonical' > newlines on either --- in either case refs would almost have to have > both installed --- or we should find out in which cases it actually > makes a difference in either version, and disallow those. (I suspect > the -X flag, for some reason, and -F at end of line). > No, it's not an OS issue. Of course something must be done for people with buggy browsers which definitely exist. But by default you should take what's in the text field, replace cr lf by \n and store in a file. Now perl actually has a weird rule that \r before \n is in fact dropped by the parser. Which is how perl works and has nothing to do with transfer issues. So if you want to print carriage return followed by newline, you can write print"\cM\cM " which is 10 strokes in standard golf notation (I wrote the single byte carriage return as the three bytes \cM in case *mailprograms* in fact mangle it). That has nothing to do with transfer issues, it's also true if you put the cr literally in a file with an editor. The browser should send this as: p r i n t " cr cr cr lf " If your pack compressor is unlucky enough to need that sequence, too bad, you loose one stroke, on whichever os you are or whichever browser you use. (notice how in this text i carefully tried to use \n for logical newline and lf for linefeed. so on windows in textmode the \n will end up as cr lf in the raw bytes of the file. Also carefully distinguish the logical bytes from the raw bytes that end up on disk) The only question is how windows reads the source (I don't have windows, so I can't check). If in textmode, also write the file in textmode. if in binmode, also write the file in binmode. That should normalize it so that judging does not depend on your os, and a certain entry will always be treated the same when sent using a specific browser, whether it goes to windows or not. It still means you got to do something for people with buggy browsers that friendly strip any extra cr or do NOT send the CR before LF for a \n in the first place. The proposed "escape methods" should solve that in fact (usually you wouldn't need to do this even for a buggy browser if the server converts bare lf to \n too) unless a person *wants* to force an extra cr before the \n. ans yes, that needs cr cr \n, and costs him three strokes. Please don't start confusing technical troubles (file formats, transfer formats, storage formats) with what a program byte count is. Perl has very specific rules for what it thinks is the input character stream, which are not ambiguous or OS dependent. >> I would have a tendency to disallow a byte that matched [^ -~\n\t] >> if I were in charge (oh, wait, I will be :) > > That would certainly make things easier --- but you'd probably have > people grumbling about how 'really' their solutions were shorter than > the winner because they had more $^X or \0 that should have been one > less char... If it was clearly in the rules at tournament start I'd not grumble about the extra char. That would just be how the rules work. The judges can count however they want to. But in any more general golf discussions i'd call $^T 2 strokes, even if in the tournament it counted as 3. I can count however I want too.
