World: r3wp

ah ok  good to know !

Switching to bitwise operations:

int-2-char: func [n [integer! decimal!]] [
	n: to integer! n
	head insert insert insert insert make string! 4
		to char! shift/logical n 24
		to char! 255 and shift/logical n 16
		to char! 255 and shift/logical n 8
		to char! 255 and n

]

Note that this is R2 code, and it depends on R2's 32bit integers 
and SHIFT behavior.

umh... but this fails if I pass a number > 2^31

Try the last version then, tell me if it works.

Perhaps removing the n: to integer! n from the math version, instead 
of the bitwise version.

your function works well, but I'm getting random protocol fails

It's strange ... every 40-50 times chrome does not connect to ws 
on the server

need to sleep. 
Thanks Brian for the help :-)

It might be that the new function is fast enough that you are running 
into timing errors in Chrome...

The bug was my fault, I was using a wrong variable name.
Thanks all for the help.

The complete (working) function to calculate the challenging code 
server side in web socket protocol is:

ws-chall: funct [header [string!]] [		
	
	cnt: funct [k] [
		n: copy "" 
		ns: 0 
		repeat x k [
			if all [x >= #"0" x <= #"9"][
				append n x
			] 
			if x = #" " [
				ns: ns + 1
			]
		]
		if ns = 0 [
			return none
		]			
		(to decimal! n) / ns
	]
	
	int-2-char: funct [n [integer! decimal!]] [
		;n: to decimal! n
		head insert insert insert insert make string! 4
			to char! n / 16777216
			to char! (n // 16777216) / 65536 
			to char! (n // 65536) / 256
			to char! n // 256
	]

	attempt [
		t: parse/all replace/all header crlf lf "^/"

  l: copy [] repeat x t [if n: find x ":" [insert tail l reduce [copy/part 
  x (index? n) - 1 next n]]] l: head l
		k1: next select l "Sec-WebSocket-Key1"
		k2: next select l "Sec-WebSocket-Key2"
		k3: next next find header "^/^/"
		aux1: cnt k1
		aux2: cnt k2
	]

	if any [none? aux1 none? aux2 none? k3] [return ""]

 to-string checksum/method rejoin [int-2-char aux1 int-2-char aux2 
 k3] 'md5		
]

the protocol is described here: http://www.whatwg.org/specs/web-socket-protocol/

why  join "a" find "x" "abc" gives "anone" ? Is it useful ?

JOIN concatenates based on the first argument datatype.

[Henrik was faster] so the second argument gets changed to the type 
of the first. Or, failing that, both are changed to string!
Try these to see:
   join "a" [1 2 3]
   join 26-jun-2010 "999"

this seems correct, but none isn't a special type?  I would like 
to use it as "neutral value" in operations

IMHO join "a" none should give "a" , length? none should give 0 and 
next none should give none

because every time I use "find" I have to check the return value

@Davide: I've actually thought the same thing about none, with respect 
to joining (though I think [0 = length? none] would be unwise, just 
as [true = true? 0] would be a mistake).

Yet in Rebol sometimes the "tail wags the dog"... there are often 
deeply entrenched reasons where some implementation detail of how 
X functionality is built on top of Y functionality means you get 
a certain behavior... like, if none didn't print as "none" it would 
break the reflection model or something with MOLD.  The go-to person 
on telling you the underlying facts of the matter is generally BrianH. 
 :)

Rebol programming can be very much like a trapeze without a safety 
net.  I have bent some of the rules in a dialect I made where (for 
instance) you can use constants or words as the clauses in if or 
either conditions.  So you can write things like [str: either condition 
"truestring" "falsestring"], instead of [str: either condition ["truestring"] 
["falsestring"]]

Rebol could do this by default, but people screw up enough as it 
is.  Is it worth the potential errors to allow this?  Absolutely 
not...

I think your "none = next none" falls in that category as well... 
it can be useful here or there, sure, but most of the time you're 
probably masking bugs.

Or making them harder to find...

fork you probably are right, but I still think that  length? none 
should not stop the script with an error.
Could'n it produce a "warnig" only or a catchable error instead?

like "error_reporting(x)" in php let me choose which kind of error 
intercept

Well Rebol is very flexible, if you disagree with the choices made 
you can indeed write your own LENG? or whatever which reacts specially 
to NONE and says 0.

what I do is normally wrap such code in an ALL block. NONE can mean 
so many things and it's best to trap a NONE where you know it appears 
during an operation that requires a series as input.

But 90% of the time, when you find a Rebol decision when you are 
not used to the language and study it after a time you will find 
it was made after a lot of deliberation.

Right. Many designs in later REBOL versions are based on code patterns 
after writing many scripts in early REBOL versions.

For better or worse, this thing has been cooked and tweaked for far 
more than a decade... so there's a lot of experience guiding the 
choices, especially if you're using R3.  (R2 had rather more clunky 
edges to it when viewed in hindsight.)

most of the time you're probably masking bugs
 - exactly.

Now if all these accepted NONE and returned 0 at the end:

length? find find find my-string "a" "b" "c"
== 0

where would the error be?

in an opposite, REMOVE supports NONE:

remove find string "something"

I think we had a similar discussion about index? .. it errors when 
find returns none

Yep, this discussion is recurring. There are pros and cons.
I would like to know the opinion of Carl about this.

#[none] could be a special "transient" value which impacts the behavior 
of DO .

Allowing to passthru a chain of functions without breaking the flow.

That would destroy the locality of errors. Every time you pass through 
none, it takes you further away from the code that resulted in the 
none in the first place. The further you pass it through, the harder 
it is to figure out where it came from. We have been careful about 
the balance about where none is passed through, but there are still 
some tweaks to go.

The INDEX? case has been covered by a CureCode discussion, and it 
looks like a good idea. For LENGTH?, the same behavior of returning 
none when passed none would make just as much sense. Under no circumstances 
should INDEX? or LENGTH? return an integer when passed none, not 
even 0.

Davide, REBOL doesn't have a neutral value for any type. This is 
by design. What we have instead is a value that can be used to mean 
nothing: none. And we have control structures to convert non-values 
to a default value: ANY and DEFAULT. R3's control structures are 
built around that principle, including the changes to the ordinal 
functions and EXTRACT.

@BrianH: Agree on that point 100%, but...

>> append "mystring" none   
== "mystringnone"

That does not have the right "feeling" to me.

Again, this is the awkward dynamic between consistency and intuition. 
 If you can state an invariant, like "If S is a string, then append 
S FOO is equivalent to append S to-string FOO" (for example) then 
it might be like "oh, it makes sense once you know that rule".  But 
you've got to find the layer at which people program, and this is 
when I start using the phrase "tail wagging the dog" because people 
are being asked to program at the APPEND layer so the implementation 
details of append should be secondary to what is sensible.

We can't make it trigger an error, because appending none is valid 
in some circumstances. And having the word "none" appended is good 
for flagging errors in developers' code. Really, the error is that 
you didn't screen for none when clearly (by your reaction) you didn't 
want to append none.

But we can only know that not screening for none was an error by 
your reaction. For others, it wouldn't be an error.

And since REBOL can't see your reaction, it has to go by what you 
said to do, not what think you wanted it to do.

join "a" any [ find "x" "abc" copy "" ]

One just has to be prepared for the failed find

I know what you mean, as appending none to a block does add a "none". 
 Though APPEND [A B] NONE currently seems to do the same thing as 
APPEND [A B] 'NONE.  I would be interested to know the side effects 
of saying APPEND [A B] NONE gave [A B] while APPEND [A B] 'NONE gave 
[A B NONE].

What you said to do is append none to a string. By your reaction, 
you wanted to append an empty string to the string. That means this 
(assuming that you don't know that the none is there):
>> append "mystring" any [none ""]
== "mystring"

The need for none to be explicitly converted to other values, rather 
than implicitly, is an intentional design choice that has been applied 
to a great deal of R3. It is not an error.