World: r3wp

Did you see such line endings in other library scripts, or do you 
think it is just me doing something strange?

I get it for all scripts, AFAICT.

Just downloaded 2 different scripts at random, same weirdness.

Now let me see what's actually going on.

Okay, I get a script library header inserted, which uses CR LF to 
terminate lines.

Then the rest of the script uses CR LF as well.

But at the very end, there's a trailing single LF.

Ah, and there's a single leading LF as well, right before the script 
library-inserted header.

We've had all sorts of fun trying to get the line endings to work 
for everyone.


There's a magic, undocumented URL parameter you can add to the URL 
that might make a difference on your platform.

It is MODE=????


I'll just cut'n'paste the comment from the download-a-script source... 
it may help explain it:

;; mode=windows -- the default. Makes LF or CR into CRLF
;; mode=binary  -- sends file as binary
;; mode=carl    -- saved and reloads file first as Carl thought
;;                 this would fix the problem
;; mode=text    -- the old default. Works in most cases. Just
;;                 prints the file (so sends whatever line
;;                 terminations work on the platform the library
;;                 is running on.

But we (s far as I remember) accept contributions with whatever line 
endings they come with, so some may be pre-messed with.

Yeah, unfortunately currently break line endings predictably.

That should be: currently you* break line endings predictably :)

Due to the erroneously inserted leading/trailing LF.

Just lookin at the source......We do edit line ending to try to get 
them consistent.
Perhaps consistent, but wrong!

It's not really the editing of the script per se, something is wicked 
in the surroundings.

The aim to to end up with CRLF in all defaiult cases.

Yeah, and you are achieving that.

But somewhere on the way something inserts a single LF as the very 
first and very last character.

Wait, I'll upload a hexdump of what actually goes over the wire.

Thanks....That'll help.

There you go: https://gist.github.com/c3ef82f0b05dc1aea045

You see the `0a` at very start and end?

Yes, thanks.

That is most certainly a bug.

Inside
 those LFs, everything is nicely and consistently CRLF'd.

Basically it looks like you've some PRINTs somewhere you'd rather 
want PRINs :)

Certainly a bug .... and a bit of a mystery. not obvious where they 
come from (not yet, anyway)
The dev server does it right, live does it wrong.

Hmm, if by "the dev server does it right" you mean the dev server 
has CRLF instead of LF at the start and end, I can tell you what's 
going on.

Yes I do.....What's going on!?

But in my opinion, "right" would be _no_ extraneous whitespace at 
the start/end.

The dev server is running Windows, the live server is running Linux.

And the download-script script generates the output by using PRINT. 
Which leads to a terminating LF on Linux and a CRLF on Windows.

Switch the output generation to use PRIN instead (and add a `prin 
crlf` at the start/end if you really want the extra whitespace), 
and it should be fine.

Possible.....But if you add &mode=binary, then do not do a PRINT.
We do this instead
   set-modes system/ports/output [binary: true]
    insert system/ports/output script-source
And that also looks wrong on live.

Yeah, because that's not where trouble occurs.

Most likely you have a PRINT before and after that.

Or, depending on where the SCRIPT-SOURCE in the above comes from, 
you do one unchecked reform/rejoin somewhere.

We have a print for the HTTP headers, prior to chaning modes....that 
may be part of the problem.

Maybe even in the upload process, so that the scripts are already 
stored on disk with the leading/tralinig LF.

Yeah, the HTTP header print sounds like a very plausible source.

Okay....let me look at it.

HTTP requires CRLF termination anyway, so what I usually do is sthg 
like:
prin rejoin [
  "Some-Header:" some-value crlf
  "Another-Header:" another-value crlf
  crlf
]

If you do a PRINT instead of the PRIN in this case, that will lead 
to exactly the extraneous LF we are seeing.

If you have a shell on the live server, `head script.r | hd` will 
give you a hexdump of the start of a stored script.

Maybe it is the upload inserting the extra LFs :)

Thanks for the advice and debugging.
I'll look at it more seriously tomorrow.

Meanwhile, does this experimental option make it bettter or worse:

    http://www.rebol.org/download-a-script.r?script-name=base-convert.r&mode=andreas

Hehe, mode=text is already working fine for me.

:)
And that hasn't changed at all.

But yes, mode=andreas looks good. No leading and trailing whitespace!

Thanks Oldes, Peter and Petr for the Rebbies nomination. If I win, 
I will of course use my year to work with children and animals for 
world peace. However, it would be better to honour someone who has 
been more active in 2010; my REBOL work has been a bit sparse this 
year. So good luck to all the nominees!


Anyway, enough of self-promotion. Oldes nomination citation notes 
that he does not like the look of REBOL.org. That's a widely shared 
sentiment, and I have much sympathy for the view.


However, REBOL.org is to some extent skinnable – look here, if you 
are logged on, for user-contributed alternative CSS schemes:
    http://www.rebol.org/css-available.r


The current look'n'feel came about by a competition for a better 
look (won by Roland Hadinger) a few years ago. And it is MUCH better 
than what we had before!


If anyone wants to craft an alternative look'n'feel, please feel 
free.


Of course, just changing the CSS is not everything: contents of menus, 
access paths, etc may need tweaking to work well with a new look. 
I am happy to play along with any suggestions that may help anyone 
who is devising a site make-over.