World: r3wp

R2 or R3? R3 can do removes from the head of the string as fast as 
it can from the tail - near instantaneously. I don't think that this 
is true for R2.

R2.

I do something similar, generating 10'000 lines and writing to a 
file takes 5-6 seconds to complete on my Intel Core 2 Duo E7400 (2.8 
Ghz) 3GB RAM.

500'000 lines a bit too much but you read the whole file into memory 
so it is possible. Your PC is a good one as well I think.

iCore 7 with 8GB RAM and a 256GB SSD ... work PC.

which means 10 times better than mine :) its normal to have that 
performance with 8GB RAM + SSD I think. file & block operations & 
foreach is fast on R2 in my experience.

Since Carl seems to have abandoned Rebol ...I wonder if this triggers 
the release of the source code held in escrow?

That would depend on what the escrow license says. Unless anyone 
here has signed a REBOL escrow source license, all we have is a vague 
description:
   http://www.rebol.com/faq.html#058

I wonder if Reichart  knows ... Qtask depends on Rebol

He may well know but I think that it is wishful thinking that the 
source may be released under an escrow agreement just because Carl 
has been quiet for a while.

Since Carl seems to have abandoned Rebol

 - there is no evidence of that. A few weeks ago, it was stated here 
 that Carl was working on R3 again.

Qtask does not depend on any changes being made to REBOL.

YY is a block of 4 decimals, which should be containing the same 
value, but it seems they are not the same to UNIQUE:

== [5.0 5.0 5.0 5.0] ; derived from a calculation
>> yy/1 == yy/2
== true
>> yy/1 == yy/3
== true
>> yy/1 == yy/4
== true
>> unique yy
== [5.0 5.0] ; huh?

>> zz: [5.0 5.0 5.0 5.0] ; typed directly in
>> unique zz
== [5.0]

Seems it's already been repported:

http://www.rebol.net/cgi-bin/rambo.r?id=4093&

It's internal rounding in REBOL, is my guess. You can see it with 
R3:

>> to decimal! #{4013 FFFF FFFF FFFF}
== 5.0
>> to decimal! #{4014 0000 0000 0000}
== 5.0
>> to decimal! #{4014 0000 0000 0001} 
== 5.0

So decimals may look the same, even if they're not.

it works in R3.

In R3, you can try do a >to binary!< on the results from the calculation 
and see the difference.

In R2, you can do some rounding before calling unique.

In R3 also:

>> print mold/all to decimal! #{4013 FFFF FFFF FFFF}
4.9999999999999991
>> print mold/all to decimal! #{4014 0000 0000 0000}
5.0
>> print mold/all to decimal! #{4014 0000 0000 0001}
5.0000000000000009

see

    http://issue.cc/r3/1634

I need to extract the data from an image file so it does not include 
the "64#" header and I just have the 64 bit encoding: 

64#{
/9j/4faARXhpZgAATU0AKgAAAAgABwEPAAIAAAAESFRDAAEQAAIAAAAIAAAAYgEa
AAUAAAABAAAAagEbAAUAAAABAAAAcgEoAAMAAAABAAIAAAITAAMAAAABAAEAAIdp
is3eIoxUdG7n/9k=
}


I just wnat the stuff between the quotes but as its a binary I can't 
seem to parse it or extract it with other methods like a text file.

x: mold 64#{
/9j/4faARXhpZgAATU0AKgAAAAgABwEPAAIAAAAESFRDAAEQAAIAAAAIAAAAYgEa
AAUAAAABAAAAagEbAAUAAAABAAAAcgEoAAMAAAABAAIAAAITAAMAAAABAAEAAIdp
is3eIoxUdG7n/9k=
}

copy/part skip x 3 -5 + length? x

Notice the molded version is twice as large as the original binary.

ENBASE

enbase! Easy! That's what I'm looking for thanks, guys.

That wasn't clear, but good you solved your problem.

The R2 dictionary for DETAB say, the string is modified, but it isn't. 
Also only the first tab before the first non-space character is replaced 
by 4 spaces, the rest with 1:

>> s: "^-abc^-def"
== "^-abc^-def"
>> detab s
== "    abc def"
>> s
== "^-abc^-def"

Has this always been this way?
Doc: http://www.rebol.com/docs/words/wdetab.html

== "^-ab^-def"
>> detab s
== "    ab  def"

The behaviour is correct (it's not just replace/all). The dictionary 
must be bad as it does not modify.

The doc above is not so bad, but it's true, that in R3 it's really 
marked as: (Modifies)

But I'm not sure there is anybody left who can fix it.

Is there a reason for this?

>> shift 1 32
== 1

Ah, probably just because 32 is being // 32, as can be seen with 
this:

>> shift 2 32
== 2
>> shift 2 33
== 1

Thats right I think:
>> shift 257 32
== 257

>> shift 257 32000
== 257

which is same result as:

>> shift 257 32000 // 32
== 257

Yes

>> shift 257 32001
== 128
>> shift 257 1
== 128

at first glance a bit confusing, but actually it's ok. >> shift 257 
65 == 128

I see potential application malfunction. It's ok to mod by 32 for 
a rotate function, as it gives same result, but not a shift, I think.

Think what will happen, if the application move from 32-bit to 64-bit.

And the mod by 32 for a rotate is only ok on a 32-bit system, on 
a 64-bit it's mod by 64. And only for integers, not binaries etc.

That's right, but only if your "interpreter" supports 64 bit integers.

As for R2, its no problem, but for others it is.

Hm, implementing SHIFT in World gives me second thought. The C operators 
>> and << works as doing internal modulus. So checking for number 
of shift will hit on performance. So it's probably better to just 
go with it and let it be up to the user to eventually check for this.

What's the idea with SHIFTing a binary! ?

>> b: #{80402010}   
== #{80402010}
>> shift b 2
== #{20100804}
>> shift b 2
== #{08040201}	; so far so good
>> shift b 2
== #{02010000}	; but now we're loosing information
>> shift b 2
== #{00000000}


So SHIFT of a binary! just shift each byte and don't carry bits over 
to the next. What is this used for?

Its no sense SHIFTing bytes in binary, we can simply use series functions, 
append #{00}, copy/part etc. Shifting bits in binary could be more 
useful for graphics operations (not so sure)

My example is doing bit shifting right (decreasing value) by 2 bits 
at a time. The bits falling off each byte isn't carried over to the 
next byte.

In your example above it shifts bytes not bits. Even shifting bits 
in binary without carrying bits over to the next bytes doesn't look 
useful.

Oh sorry, your second example. Ok.

Does anyone have