World: r3wp

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

a function to sort jpeg files from a digital camea by exif date?

IIRC, someone did EXIF reader. Have you tried looking into rebol.org?

Pekr, thanks for responding. I'll look there.

There are two scripts from Piotr Gapinski, related to EXIF. IIRC 
Oldes did ImageMagick wrapping,maybe it can do some EXIF stuff too 
...

or you can use command line tool like Exiftool, and wrap the result 
using CALLL in REBOL and parse the output?

>> buff: copy ""
>> call/wait/output "exiftool img_0033.jpg" buff

works like a charm, returning several pages of txt formatted output 
- http://www.sno.phy.queensu.ca/~phil/exiftool/

parse/all buff [thru "Create Date" thru ": " copy EXIF-create-date 
to newline]

your value is in EXIF-create-date ....

Wow! Thanks for the help Pekr!

Dunno how fast it is going to be though, exiftool looks slow, when 
called from REBOL. Might take some time to extract info from xy files 
in directory ...

I have uploaded my latest EXIF-parser version at github - https://github.com/Oldes/rs/blob/master/projects/exif-parser/latest/exif-parser.r

To sort files you can use for example:

dir: %/e/DCIM/100CANON/
t: now/time/precise
result: copy []
foreach file read dir [
	error? try [
		ctx-exif/parse-file dir/:file
		exifdate: ctx-exif/get-tag-value 306
		repend result [exifdate dir/:file]
	]
]

sort/skip result 2

print ["sorted" (length? result) / 2 "files in" now/time/precise 
- t]
result

;>>sorted 120 files in 0:00:00.153

(it could be probably optimized as the script is from year 2004, 
but I don't care too much)

Oldes, many thanks!  I can''t work on this right now, but as soon 
as I can I'll report back.

Any news about a new year version of REBOL ?