World: r3wp

I'm glad you tackled the connecting dots problem, though I don't 
think your solution worked... but it was in the spirit of my desire 
to see Rebol step up to these challenges and prove itself.  Because 
if it can win at anything, it can win at this.

And like I say about my Hourglass solution vs. the "winning" golfscript 
solution... it broke the rules, it has no reusable parts, it exploits 
symmetries and gimmicks in the problem such that if the problem specification 
changed only slightly you'd have to rewrite the whole thing.

Well, i saw the remaining problems in my code, correcting them would 
not enlarge so much the length of the code

In solving it I found that like with many code golf problems there 
are some little "nuances" which emerge as you look at it...

Bit I don't think we can beat the shortest solution

*But

Specifically, there are cases when lower numbered dots can connect 
and cross over the second digit of a larger numbered dot

That forces you to basically build a map of the numbers before you 
start drawing the lines :(

Yes I finally understood that point

A lot of these problems have gotchas like that where you think "oh, 
easy I'll just do it like this..."

Then you get there and realize "oh crap" and suddenly you've added 
like 50 characters

:-)

Did you go through my solution at all?

Sorry not at all, If you could decipher your code for me...

It's simple at heart.

Well, if what BrianH is true I may need to write "unrebmu" sooner 
rather than later

So this line here: "w [j: d ++ n] [ro g [x j y j]]" is that building 
of the initial coordinate map.  It keeps incrementing n, and passing 
it to the "d" function which returns either the coordinate pair where 
that digit resides (or none if the digit could not be found).

while [j: d (++ n)] [repend/only g [x (j) y (j)]]

Er, no the d function returns the series position

And it is the x and y functions which translate those into coordinates.

So the issue we discussed about needing to build the map ahead of 
time is taken care of right there.  After this step, G is an ordered 
series of two-element blocks... each with two integers, the coordinate 
pair of where that dot is.

Then clearly we loop through G.  On each loop iteration, B is the 
coordinates of the start of our pen and F is the location of the 
finish of our pen.

We keep bumping B until we reach F.  How much do we bump the X coordinate 
of B and how much do we bump the Y coordinate of B on each iterator 
step?  That is stored in H and V which are in the set (-1, 0, 1).

; string containing the (l)etters used for walls
l: {-|\/}

Which letter we use to draw the wall depends on h and v, right?  
If our vertical bump is zero, we know we want the first element. 
 If our horizontal bump is zero we know we want the second.  If the 
bump is [1 1] or [-1 -1] we know we want the "/" (third element), 
otherwise the fourth ("\").  This line is really rather boring:

ch c b pc l ez v 1 [ez h 2 [ee h v 3 4]]

change c b pick L either-zero v 1 [either-zero h 2 [either-equal 
h v 3 4]]

Hopefully you get the idea.  It's really simple.  I'm not trying 
to beat the winners based on libraries or tricks, I'm not trying 
to write clever code, I'm writing REALLY boring straightforward code 
with function definitions and everything which can be adapted easily 
if the problem spec is adapted.  And still within a stone's throw 
of the winners, or even beating them.  In this case I got 218 characters 
compared to the winning "perl" at 222.

And that perl is garbage.  No functions, no reusability, no intelligence.

Meaningless letters, far from being able to handle N-digit numbers... 
y'know, the usual.  I'm standing on the shoulders of giants here, 
but that's why I can see farther.

Your unrebmu proposal would be a compiled dialect, with the target 
being DO dialect code. This is a good technique for many dialects, 
and can be very fast. That makes it a good idea for a demo.

I wonder how rebmu would compare to COMPRESS for space savings? Compressed 
scripts/modules are planned for R3 (actually, implemented but not 
included yet). This includes binary! syntax encoded compressed data.

It's a good question, and regarding that, I noted that many of the 
solutions to Code Golf problems utilize base-64.

Janko wanted some script obfuscator and as I see, Rebmu is already 
less readable than Brainfuck, so I think it's a good candidate.

@Rebolek: For the sake of the psychological testing, these Code Golf 
problems I'm solving... I'm actually solving *in Rebmu*, mushed form.

I break into Rebol of course for debugging, probing etc, but that's 
just inserted in the margins, then I delete them.

I am driven largely by spite for Perl, to be honest.

Spite for Perl is a noble motivation :)

But also a desire to get "fringe"/"creative" people to become aware 
of Rebol.

That's why making an ultra-cool demo is a priority :)

@BrianH, continuing: So I thought "well, Rebol can uncompress, why 
not make an operator that takes compressed data and uncompresses 
it".  I was surprised that compress was returning significantly larger 
data than the input for small inputs.  What's up with that?

I assume it's because of using a standard that expected the "do not 
compress" to be taken care of at a higher level.

In any case, the single-character operators in Rebmu are a tricky 
bunch for reasons I explained above, but one case that they do pop 
up in is assignments where the left hand is an all-caps target (set-word) 
and the right hand is a string or block or something.  That's when 
you can get them easily.

Although this bunch is in flux, I tried making [^ foo] map to [to-string 
debase foo].  This means S^"badfjakshdg--" (or whatever) will give 
you the un-base-64'd string.

s: ^ "badfjakshdg--"

COMPRESS uses the Deflate algorithm, plus an integer on the end for 
the length of the uncompressed data, for allocation purposes. It 
has the same limitations as any other Deflate compressor (zip, gzip, 
zlib, png, ...).

I think there's a big gap between the usefulness of a spanish or 
Italian localization and a chinese localization.

 - actually not, as Jerry mentioned some time ago, there are exactly 
 the same reasons why it is not useful

@Ladislav: Tonight I was discussing the Firefox/Mozilla thing with 
my roommate.  It was an issue where Mozilla was building a lot of 
functional stuff, but they didn't have quite the ability or agility 
to see and take advantage of opportunities.  Some weird dude came 
along and said "Hey, I'm gonna chop all this stuff off, and insert 
this stuff, and call it 'Firefox', and let's see what the heck happens..."

It would have enough overhead that it should not be there by default 
- LOAD does enough as it is. However, it might be an interesting 
tool for somebody, and a great demonstration. And it can be an add-on 
module, which makes it an even better demonstration.

The layman today does not know what Mozilla even is.