World: r3wp

It's enabled but does not sync as fast as the drift and I'm having 
trouble doing it manually...keep getting an error and I tried several 
time servers.

if I have a file with url-encoded chars in it, what's the fastest 
way to decode them?

dehex

Thank you very much. I forgot that.

what is the fastest way to find the number of digits in a number, 
if you want to use it to calculate the pixel width of the number 
for a table column? simply using:

length? form number

?

My guess would be:

1 + to integer! log-10 number

, but that's slightly slower than yours, it seems.

Can your number both be integer and decimal?

it's most likely to be a decimal

Then mine won't work.

I may have found another way without needing to work on the length. 
Thanks, anyway.

:)

but that's slightly slower than yours, it seems
 - strange, here it looks much faster than length? form

>> number: 1234                                       
== 1234
>> time [loop 1000000 [1 + to integer! log-10 number]]
== 0:00:00.293239
>> time [loop 1000000 [length? form number]]          
== 0:00:00.28022

On R2 version 2.7.7.2.5

I see the log-10 loop as around 18% faster under core 2.7.8.

So this optimisation depends, it seems, on specific machines and 
versions.

It would depend on the relative speeds of the CPU and the FPU

Ran code like the following against a 600MB file of 500,000+ lines:

	file: read/lines %log.csv
	foreach line file [
		remove/part line 1000
	]


and was surprised that the foreach loop was near instantaneous (I'd 
assumed 500,000+ removes would at least take a second or two). I'm 
not complaining, just curious. ;)

Does it work? Or do you hit a 4GB boundary with some internal structures, 
so there is an error, you don't get out?

It certainly worked (file size was 400MB not 600MB).

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