World: r3wp

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.

I just noticed that there are 1023 scripts on REBOL.org. Who wants 
to be 2 **10?

The wait is over!
It was Massimiliano's REBOL IDE script. Now for the 2048th!
   http://www.rebol.org/view-script.r?script=rebolide.r

?

The 1024th script on REBOL.org :)

fine 1024 script burried one on top of another :) nice !!!

the goal is to pile them up till they reach the sky ?

The goal is for them to be there and useful to those who need them. 
And polite.

usefull without the R3 support and without having desktop soft in 
R3  humm can I doubt about that ?

rebol.org liked to rebol/view 2 desktop is something we will never 
see in R3 anytime soon so who cares R2 is deprecated and R3 will 
never be as great and inovative as R3 used to be... My main claim 
about R2 is that the technologies proposed in it were great but unfinished 
... and simply in R3 those are not even talked about anymore (reb/service 
reb/plugin reb/console reb/desktop) I know if not happy I better 
shut my mouth but I wouldn't so what ?

If someone finds it useful and worth working the bugs out of, cool. 
It doesn't have to be useful to everyone.

yeah but who will be that someone ? me ? hum ... sorry dude i have 
better things to do than wasting my time in fruitless projects .... 
that will only be used by me ... I understoud too well that those 
past 10 years...

In 3 out of 4 of those cases you gave, they couldn't be finished 
because of security issues that could not be fixed in R2. R3 has 
made a lot of headway towards fixing those security issues, mostly 
because we kept them in mind when we made the incompatible changes 
(not everything was incompatible). As more participants use REBOL 
more, the limitations of it will be resolved. That is how the R2 
backports started, for instance.