World: r3wp

actually, I only started using VS last week.


when I did my previous Extensions test, I used VS, but didn't play 
at all wit it... I had used the whole project supplied by carl.

but having a page with screen grabs would be much better.

Yes, I agree.

The thing with  MinGW is to get this installation right. Which is 
far from easy, like the make stuff shows.

For me the host-code was simple to compile: make

That was it, worked on the first shot.

But I didn't have mingw in my path.  I think that was the problem.

Ah, that would do it. The MinGW installer says it's going to set 
the path, but it fails at doing so. You have to do it yourself.

Yeah, I don't care for the instructions we have for mingw.  We shouldn't 
have to copy the mingw32-make.exe file to make.exe.  We should just 
have to go to the rebol directory and type mingw32-make and be done 
with it.

R3 is really starting to grow on me  :-D

I caught the same disease.
I think that is unfortunately incurable.

this line brought a smile to my face:

retrieve: does [take/last data]

My only problem with R3 right now is that there is no codec for text 
reading .  This means I can't properly import C files for example, 
unless I convert them to utf-8 with something else first.


Has anyone done (or started to work on) a simple character mapping 
engine?

the new bitset! datatype is absolutely fantastic!  we can actually 
USE it now  ;-)

before it was basically just a parse accelerator

guys, to make things clear for me - recent efforts - if someone reports, 
that R3 compiles on system XY, does it mean that we are able to build 
R3 on such a platform = it is build and usable on such a platform? 
Or are we reporting that Carl is able to compile just DLL on a target 
platform?

Because if it is a former, it means that in 3 weeks we ported actual 
REBOL version (even if pre-beta) to more platforms, than R2 got to 
in last 10 years :-)

I think we need a simple document or FAQ that answers what it takes 
to port R3 to a completely new CPU/OS platform. Just 10-15 bulletpoints.

there will be of-course difference in porting Core, vs. for .e.g 
View ...

pekr, once carl can build a dynamic library on a platform, someone 
can do the rest, using the common host code.  as most alternative 
OSes support some level of unix C libraries, the adaptation of the 
host code should not be a big issue.  since the code is based on 
ANSI 90, just about every platform out there supports that.


and yes, on every platform that Carl has compiled the host in the 
last weeks, this means R3 runs and is usable on that platform.

HOST KIT FOR LINUX!   And I'm three days behind already.  Why didn't 
anyone send a memo to read the blog?   :)


Woohoo, back to REBOL programming...     And just so ya know, when 
I embed this in OC it'll be CORE BOL  ;)

:-D

what's the best way to convert a hex string to a decimal value in 
R3?

One way is to start with an issue! rather than hex
    >> to-integer #100
    == 256

perfect... just what I needed  thanks  :-)

I got some strange results with decima!

But check it works for large values first.....

>>  to integer! #{2710}         
 
== 10000


>>  to decimal! #{2710}
 
== 4.94065645841247e-320

decimal is broken with issue.

>>  to decimal! to binary! 10000
 
== 4.94065645841247e-320

>>  to integer! to binary! 10000 

== 10000

Probably explained by this Curecode report
   http://www.curecode.org/rebol3/ticket.rsp?id=547

There is something that doesn't seem correct about the following: 
:

>> to decimal! to integer! to binary! 10000

== 10000.0

>>  to decimal! to binary! 10000         
 
== 4.94065645841247e-320

not a bug, as explained in the curecode ticket

decimals and integers are not hard coded the same way in a binary

00

Peter: 

>> to binary! 10000.0
== #{40C3880000000000}

>> to binary! 10000
== #{0000000000002710}

Why do you think they should be the same?

I don't. It's the behaviour of to-decimal that I don't understand;

>> to decimal! #{0000000000002710}
== 4.94065645841247e-320

In R2 this would raise a script error:

>> to decimal! to binary! 10000   
** Script Error: Invalid argument: #{3130303030}
** Near: to decimal! to binary! 10000

In R2:
>> to binary! 10000
== #{3130303030}

So we get the ascii value of each digit in the number. In R3:

>> to binary! 10000
== #{0000000000002710}


The number is seen as a 64-bit integer, and we get the binary representation 
of that.

then why do you think, that this is a bug?:

>> to decimal! to binary! 10000.0
== 10000.0

If you want to know more, read http://www.rebol.net/wiki/Decimals-64

Maxim: "what's the best way to convert a hex string to a decimal 
value in R3?" - Try this:
>> pi
== 3.14159265358979
>> enbase/base to-binary pi 16
== "400921FB54442D18"
>> to-decimal debase/base "400921FB54442D18" 16
== 3.14159265358979
>> to-decimal debase/base enbase/base to-binary pi 16 16
== 3.14159265358979


You asked for the best way: No method that uses the issue! type for 
binary conversions could be considered the best way.

Not sure what specific data transformation Maxim needs.

I'd be interested in the REBOL code to do would would seem to be 
a simple transformation:
  How do I get from:

    #{0100}   ;; two bytes of binary, perhaps read from an external file
   to:

    256          ;; the equivalent integer (given the implicit endian 
    assumptions)

if it's for storing usage, then restoring, perhaps the base 64 format 
is enough.

>> enbase to-binary pi
== "QAkh+1RELRg="

>> to-decimal debase enbase to-binary pi
== 3.14159265358979

and it take less size (besides, it has always the same length)

Ah, it's those implicit endian assumptions that can trip you up, 
Sunanda. But here's a good method that for big-endian 64-bit on R3:
>> to-integer #{0100}
== 256

that for -> that works for

Thanks, Brian......I'd tried that, and it did not work for me. Must 
have been having one of those blond moments, because it works now 
:)

newb instant ;-)

It should work for 32-bit integers too, but there isn't yet a build 
that supports them (though the source does).

U mean something like this ?
>> to-integer #{01000000}
== 16777216