World: r3wp

Well I'm just a typical new user trying out the demos from viewtop. 
 I know there's a few ways to execute code

David, you might also want to look at the r2-forward script by BrianH 
- it's intended to retrofit a good amount of the newer R3 functionality 
into R2. You can dowload that using R3 chat.

Most of R2/Forward was added to R2 itself with the 2.7.7 release. 
The rest was added to 2.7.8 (release pending). There are some limits 
as to what R3 functionality can be retrofitted into R2, but you'd 
be surprised. Also, look at the source - it's also meant to serve 
as documentation about differences between R3 and R2, although it 
can be a bit on the advanced side here and there.

Brian, what's the intent wrt delect? With Carl's most recent wiki 
page describing commands, it seems that a fair amount of  delect's 
parsing power (optional, out of order args) won't be available using 
these - is delect going to remain?

It's unknown at this point whether DELECT will remain: The command-processing 
functionality of DELECT has been moved into DO-COMMAND. I'm guessing 
that DELECT will end up being a preprocessor that generates DO-COMMAND 
blocks; the wiki you mentioned says that a similar preprocessor is 
run on Draw blocks before they are sent to DO-COMMAND (the "For special 
draw dialects..." paragraph).

How can I convert money to a number or a char ?

>> to integer! $1
** Script Error: Invalid argument: $1.00
** Near: to integer! $1.00

>> to char! $65
** Script Error: Invalid argument: $65.00
** Where: halt-view
** Near: to char! $65.00

Easy answer: Use R3.
Hard answer: To string and back.
>> to-decimal next mold $1
== 1.0

decimal/money not being convertible to one another is a strange ommission 
in R2

>> to-integer next mold $1
== 1

We did a really thorough revamp of conversion in R3. And doing the 
same in R2 would be comparable in scope.

>> $12.34 / $1.00
== 12.34

good catch!

>> $65 / $1
== 65.0

Easy answer: Use divide :)

Great way to exploit a terrible bug for the benefit of all! :)

This is math ... not a bug

yes exactly.

The type conversion is a bug. The math is the benefit.

if you divided by a decimal, then it should return a money type. 
  which it does.

no its very consistent.... how many dollars in 65 dollars?   one... 
  not one dollar.

6 dollars divided by 2 is  3 dollars... not 3

What are you saying max?

You can also use First and Second

(in R2)

Second .. true

much better ..

the use of Mold is something I would discourage to use for this purpose

the denominator is handling the return type, which is consistent 
with how you'd express the division in real life.

No string conversion, no floating point division(?); we have a winner!

I still like the "Use R3" method, but that is not always practical 
:(

How about .. use R2 1.7.8 ?

Fixing conversions is not on the roadmap for 2.7.8.

ok, 2.7.9 then

thanks for the quick answers! you guys are great


I'm building a function that computes the challenging code for  web 
socket  protocol, 

It uses unsigned 32 bit integer, so I use money instead of integer, 
to avoid overflow.

there is no advantage to use money in R2 against the decimals, they 
are pretty much the same in R2

(by the way, which is the best method to convert 32 bit integer to 
4 byte string big endian ?)

thanks ladislav, I will use decimal.

Does it have to be a string, or will binary do?

I think binary would be ok too...

this is my quick & dirty func:

int-2-char: func [n [decimal!] /local ret] [
			ret: copy "" 
			repeat k [16777216 65536 256 1] [
				append ret to char! (n / k)
				n: modulo n k
			]
			ret
		]

That function would be sped up by unrolling the loop.

one way is to use my http://www.fm.tul.cz/~ladislav/rebol/peekpoke.r

(you can find other conversions in there)

and, btw, unsigned and signed integers differ only in interpretation, 
using the same representation

thanks ladislav, but I prefer a small routine ad hoc instead of a 
generic and more complex one.
I have to be small with this code

here we go:

int-2-char: func [n [decimal!] /local ret] [
	ret: copy "" 
	append ret to char! (n / 16777216) n: modulo n 16777216
	append ret to char! (n / 65536) n: modulo n 65536
	append ret to char! (n / 256) n: modulo n 256
	append ret to char! n			
	
	ret
]

mmm there's something strange, with the first version of the function 
the protocol works, 

with the second version every 10-20 times the protocol fails to estabilish

<poker face>

they return the same values, maybe some side-effects ?